home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / internet-drafts / draft-ietf-ifmib-evolution-03.txt < prev    next >
Encoding:
Text File  |  1993-09-27  |  112.3 KB  |  3,363 lines
  1.  
  2.  
  3.       Draft               Interfaces Group Evolution   26 September 1993
  4.  
  5.  
  6.  
  7.                  Evolution of the Interfaces Group of MIB-II
  8.  
  9.                               26 September 1993
  10.  
  11.  
  12.                                Keith McCloghrie
  13.                               Hughes LAN Systems
  14.                                  kzm@hls.com
  15.  
  16.                              Frank J. Kastenholz
  17.                                  FTP Software
  18.                                 kasten@ftp.com
  19.  
  20.  
  21.  
  22.  
  23.  
  24.                              Status of this Memo
  25.  
  26.       This document is an Internet Draft.  Internet Drafts are working
  27.       documents of the Internet Engineering Task Force (IETF), its
  28.       Areas, and its Working Groups.  Note that other groups may also
  29.       distribute working documents as Internet Drafts.
  30.  
  31.       Internet Drafts are valid for a maximum of six months and may be
  32.       updated, replaced, or obsoleted by other documents at any time.
  33.       It is inappropriate to use Internet Drafts as reference material
  34.       or to cite them other than as a "work in progress".
  35.  
  36.  
  37.  
  38.  
  39.  
  40.  
  41.  
  42.  
  43.  
  44.  
  45.  
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.       Expires 26 March 1994                                     [Page 1]
  57.  
  58.  
  59.  
  60.  
  61.       Draft               Interfaces Group Evolution   26 September 1993
  62.  
  63.  
  64.       1.  Introduction
  65.  
  66.       This memo defines an experimental portion of the Management
  67.       Information Base (MIB) for use with network management protocols
  68.       in the Internet community.  In particular, it describes managed
  69.       objects used for managing Network Interfaces.
  70.  
  71.       This memo discusses the 'interfaces' group of MIB-II, especially
  72.       the experience gained from the definition of numerous media-
  73.       specific MIB modules for use in conjunction with the 'interfaces'
  74.       group for managing various sub-layers beneath the internetwork-
  75.       layer.  It proposes clarifications to, and extensions of, the
  76.       architectural issues within the current model used for the
  77.       'interfaces' group.
  78.  
  79.       This memo also includes a MIB module.  As well as including new
  80.       MIB definitions to support the architectural extensions, this MIB
  81.       module also re-specifies the 'interfaces' group of MIB-II in a
  82.       manner which is both compliant to the SNMPv2 SMI and
  83.       semantically-identical to the existing SNMPv1-based definitions.
  84.  
  85.  
  86.       1.1.  Change Log
  87.  
  88.       This section tracks changes made to the revisions of the Internet
  89.       Drafts of this document.  It will be deleted when the document is
  90.       published as an RFC.
  91.  
  92.       26 September 1993
  93.  
  94.       The following changes were made for the version of the document
  95.       dated 26 September 1993
  96.  
  97.       (1)  Minor editorial changes.
  98.  
  99.       20 September 1993
  100.  
  101.       The following changes were made for the version of the document
  102.       dated 20 September 1993
  103.  
  104.       (1)  The description text for ifType has been changed to a)
  105.            reflect that the IANA will be the source of future
  106.            assignments for the ifType value, b) that the IANA's current
  107.            policy is to keep the ifType value and transmission subtree
  108.            OIDs the same, and c) latest policies and values may be
  109.  
  110.  
  111.  
  112.  
  113.  
  114.       Expires 26 March 1994                                     [Page 2]
  115.  
  116.  
  117.  
  118.  
  119.       Draft               Interfaces Group Evolution   26 September 1993
  120.  
  121.  
  122.            obtained from a "SNMP Numbers" RFC.
  123.  
  124.       (2)  The values for ifType have been rearranged to fit with the
  125.            values assigned by the IANA as of 24 August 1993.
  126.  
  127.       (3)  Additional text has been added clarifying the meaning of
  128.            "higher layer" for input and output packet counters.
  129.  
  130.       (4)  The types of interface used in some examples were changed.
  131.  
  132.       (5)  The requirements on a media-specific MIB are expanded to
  133.            require the the specification of what ifSpecific should point
  134.            to.
  135.  
  136.       (6)  Minor editorial changes to conform with the RFC Editor's
  137.            standard format.
  138.  
  139.       23 August 1993
  140.  
  141.       The following changes were made for the version of the document
  142.       dated 23 August 1993.  These changes are listed in no particular
  143.       order.
  144.  
  145.       (1)  Some additional ifTypes were added: localTalk, smds-dxi,
  146.            frameRelayService), v35, hssi, hippi, modem
  147.  
  148.       (2)  The frame-relay value of ifType has been limited to being
  149.            just DTE.
  150.  
  151.       (3)  A new enumerated value, "unknown(4)" was added to
  152.            ifOperStatus.
  153.  
  154.       (4)  ifName was added to the ifGeneral group.
  155.  
  156.       19 July/9 August 1993
  157.  
  158.       The following changes were made for the version of the document
  159.       dated 9 August 1993.  These changes are listed in no particular
  160.       order.
  161.  
  162.       (1)  Additional text clarifying the meaning of "higher layer
  163.            protocol" has been added.
  164.  
  165.       (2)  Per the working group meeting in Amsterdam, a statement was
  166.            added stating that the 32 bit counters will always be
  167.  
  168.  
  169.  
  170.  
  171.  
  172.       Expires 26 March 1994                                     [Page 3]
  173.  
  174.  
  175.  
  176.  
  177.       Draft               Interfaces Group Evolution   26 September 1993
  178.  
  179.  
  180.            available and, when 64-bit counters are in use, will report
  181.            the least significant 32 bits of the 64 bit counters.
  182.  
  183.       (3)  Per the working group meeting in Amsterdam, strengthened the
  184.            wording of Section 3.2.3 "Virtual Circuits" that recommends
  185.            that entries in the ifTable not be assigned to connections.
  186.  
  187.       (4)  Per the working group meeting in Amsterdam, added text to
  188.            Section 3.2.3 "Virtual Circuits" that requires that the MIB
  189.            designer present rationale if entries in the ifTable are
  190.            assigned to connections.
  191.  
  192.       (5)  Per the working group meeting in Amsterdam, ifOutQLen has
  193.            been deprecated.
  194.  
  195.       (6)  Per the working group meeting in Amsterdam,
  196.            ifExtnsPromiscuous has been retained in the extension of the
  197.            ifTable.
  198.  
  199.       (7)  Per the working group meeting in Amsterdam, ifExtnsRevWare
  200.            and ifExtnsChipSet were deleted from the MIB on the basis
  201.            that their exact use is very unclear.  It is quite possible
  202.            in many interface architectures to "mix and match" chipsets
  203.            and drivers, leading to ambiguity as to the intended contents
  204.            of these objects.
  205.  
  206.       (8)  Per the working group meeting in Amsterdam, the
  207.            ifExtnsTestTable has been replaced with the ifTestTable.
  208.  
  209.       (9)  Per the working group meeting in Amsterdam, the text
  210.            describing the ifTestGroup's implementation status has been
  211.            altered to reflect the fact that a media-specific mib should
  212.            use the ifTestTable for any tests it defines, and therefore
  213.            may make implementation of the group mandatory.
  214.  
  215.       (10) Per the working group meeting in Amsterdam, 2 interface speed
  216.            steps for using 64 bit counters are specified.  The first is
  217.            for using 64-bit octet counters.  The second is for using
  218.            64-bit packet counters.
  219.  
  220.       (11) Per the working group meeting in Amsterdam, the 64-bit error
  221.            counters have been removed.
  222.  
  223.       (12) Per the working group meeting in Amsterdam, a section has
  224.            been added that provides the rationale for the default
  225.  
  226.  
  227.  
  228.  
  229.  
  230.       Expires 26 March 1994                                     [Page 4]
  231.  
  232.  
  233.  
  234.  
  235.       Draft               Interfaces Group Evolution   26 September 1993
  236.  
  237.  
  238.            setting specified for ifLinkUpDownTrapEnable.
  239.  
  240.       (13) The semantics of ifSpecific have been tightened up, to
  241.            recommend the use of the semantics of InstancePointer, even
  242.            though the SYNTAX isn't changed so as to: not require
  243.            deprecating it, and not make existing implementations non-
  244.            compliant.
  245.  
  246.       (14) The ifTable has been split into two tables.  The first table
  247.            contains all objects that were in the original ifTable.  The
  248.            second table contains all objects that have been added by
  249.            this MIB.
  250.  
  251.       (15) In the ifTestTable, the use of ifTestCommunity (and
  252.            ifTestContext which would also have been required for SNMPv2)
  253.            and ifExtnsTestRequestId objects have been replaced by the
  254.            new ifTestId, ifTestStatus, and ifTestOwner objects.
  255.  
  256.       (16) Some new enumerated values for ifType have been added.
  257.  
  258.       (17) The compliance statements have been updated so that support
  259.            for the 'testing(3)' value of ifAdminStatus is not required.
  260.  
  261.       (18) Several ASN.1 and SMI errors were fixed.
  262.  
  263.       (19) Several spelling and grammar errors were fixed.
  264.  
  265.  
  266.  
  267.  
  268.  
  269.  
  270.  
  271.  
  272.  
  273.  
  274.  
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282.  
  283.  
  284.  
  285.  
  286.  
  287.  
  288.       Expires 26 March 1994                                     [Page 5]
  289.  
  290.  
  291.  
  292.  
  293.       Draft               Interfaces Group Evolution   26 September 1993
  294.  
  295.  
  296.       2.  The SNMPv2 Network Management Framework
  297.  
  298.       The SNMPv2 Network Management Framework consists of four major
  299.       components.  They are:
  300.  
  301.       o    RFC 1442 which defines the SMI, the mechanisms used for
  302.            describing and naming objects for the purpose of management.
  303.  
  304.       o    RFC 1213 defines MIB-II, the core set of managed objects for
  305.            the Internet suite of protocols.
  306.  
  307.       o    RFC 1445 which defines the administrative and other
  308.            architectural aspects of the framework.
  309.  
  310.       o    RFC 1448 which defines the protocol used for network access
  311.            to managed objects.
  312.  
  313.       The Framework permits new objects to be defined for the purpose of
  314.       experimentation and evaluation.
  315.  
  316.  
  317.       2.1.  Object Definitions
  318.  
  319.       Managed objects are accessed via a virtual information store,
  320.       termed the Management Information Base or MIB.  Objects in the MIB
  321.       are defined using the subset of Abstract Syntax Notation One
  322.       (ASN.1) defined in the SMI.  In particular, each object object
  323.       type is named by an OBJECT IDENTIFIER, an administratively
  324.       assigned name.  The object type together with an object instance
  325.       serves to uniquely identify a specific instantiation of the
  326.       object.  For human convenience, we often use a textual string,
  327.       termed the descriptor, to refer to the object type.
  328.  
  329.  
  330.  
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338.  
  339.  
  340.  
  341.  
  342.  
  343.  
  344.  
  345.  
  346.       Expires 26 March 1994                                     [Page 6]
  347.  
  348.  
  349.  
  350.  
  351.       Draft               Interfaces Group Evolution   26 September 1993
  352.  
  353.  
  354.       3.  Experience with the Interfaces Group
  355.  
  356.       One of the strengths of internetwork-layer protocols such as IP
  357.       [6] is that they are designed to run over any network interface.
  358.       In achieving this, IP considers any and all protocols it runs over
  359.       as a single "network interface" layer.  A similar view is taken by
  360.       other internetwork-layer protocols.  This concept is represented
  361.       in MIB-II by the 'interfaces' group which defines a generic set of
  362.       managed objects such that any network interface can be managed in
  363.       an interface-independent manner through these managed objects.
  364.       The 'interfaces' group provides the means for additional managed
  365.       objects specific to particular types of network interface (e.g., a
  366.       specific medium such as Ethernet) to be defined as extensions to
  367.       the 'interfaces' group for media-specific management.  Since the
  368.       standardization of MIB-II, many such media-specific MIB modules
  369.       have been defined.
  370.  
  371.       Experience in defining these media-specific MIB modules has shown
  372.       that the model defined by MIB-II is too simplistic and/or static
  373.       for some types of media-specific management.  As a result, some of
  374.       these media-specific MIB modules have assumed an
  375.       evolution/loosening of the model.  This memo is a proposal to
  376.       document/standardize the evolution of the model and to fill in the
  377.       gaps caused by that evolution.
  378.  
  379.       A previous effort to extend the interfaces group resulted in the
  380.       publication of RFC 1229 [7].  As part of defining the evolution of
  381.       the interfaces group, this memo applies that evolution to, and
  382.       thereby incorporates the RFC 1229 extensions.
  383.  
  384.  
  385.       3.1.  Areas of Clarification/Revision
  386.  
  387.       There are several areas for which experience indicates that
  388.       clarification, revision, or extension of the model would be
  389.       helpful.  The next sections discuss these.
  390.  
  391.  
  392.       3.1.1.  Interface Numbering
  393.  
  394.       MIB-II defines an object, ifNumber, whose value represents:
  395.  
  396.            "The number of network interfaces (regardless of their
  397.            current state) present on this system."
  398.  
  399.  
  400.  
  401.  
  402.  
  403.  
  404.       Expires 26 March 1994                                     [Page 7]
  405.  
  406.  
  407.  
  408.  
  409.       Draft               Interfaces Group Evolution   26 September 1993
  410.  
  411.  
  412.       Each interface is identified by a unique value of the ifIndex
  413.       object, and the description of ifIndex constrains its value as
  414.       follows:
  415.  
  416.            "Its value ranges between 1 and the value of ifNumber.  The
  417.            value for each interface must remain constant at least from
  418.            one re-initialization of the entity's network management
  419.            system to the next re-initialization."
  420.  
  421.       This constancy requirement on the value of ifIndex for a
  422.       particular interface is vital for efficient management.  However,
  423.       an increasing number of devices allow for the dynamic
  424.       addition/removal of network interfaces.  One example of this is a
  425.       dynamic ability to configure the use of SLIP/PPP over a
  426.       character-oriented port.  For such dynamic additions/removals, the
  427.       combination of the constancy requirement and the restriction that
  428.       the value of ifIndex is less than ifNumber is problematic.
  429.  
  430.  
  431.       3.1.2.  Interface Sub-Layers
  432.  
  433.       Experience in defining media-specific management information has
  434.       shown the need to distinguish between the multiple sub-layers
  435.       beneath the internetwork-layer.  In addition, there is a need to
  436.       manage these sub-layers in devices (e.g., MAC-layer bridges) which
  437.       are unaware of which, if any, internetwork protocols run over
  438.       these sub-layers.  As such, a model of having a single conceptual
  439.       row in the interfaces table (MIB-II's ifTable) represent a whole
  440.       interface underneath the internetwork-layer, and having a single
  441.       associated media-specific MIB module (referenced by the ifSpecific
  442.       object) is too simplistic.  A further problem arises with the
  443.       value of the ifType object which has enumerated values for each
  444.       type of interface.
  445.  
  446.       Consider, for example, an interface with PPP running over an HDLC
  447.       link which uses a RS232-like connector.  Each of these sub-layers
  448.       has its own media-specific MIB module.  If all of this is
  449.       represented by a single conceptual row in the ifTable, then an
  450.       enumerated value for ifType is needed for that specific
  451.       combination, and that row's ifSpecific variable can "point" to
  452.       only one of the three media-specific MIB modules.  Furthermore,
  453.       even if there was a convention for deciding which MIB module is
  454.       referenced by ifSpecific, then there is still a lack of a method
  455.       to describe the relationship of all the sub-layers of the MIB
  456.       stack.
  457.  
  458.  
  459.  
  460.  
  461.  
  462.       Expires 26 March 1994                                     [Page 8]
  463.  
  464.  
  465.  
  466.  
  467.       Draft               Interfaces Group Evolution   26 September 1993
  468.  
  469.  
  470.       An associated problem is that of upward and downward multiplexing
  471.       of the sub-layers.  An example of upward multiplexing is MLP
  472.       (Multi-Link-Procedure) which provides load-sharing over several
  473.       serial lines by appearing as a single point-to-point link to the
  474.       sub-layer(s) above.  An example of downward multiplexing would be
  475.       several instances of PPP, each framed within a separate X.25
  476.       virtual circuit, all of which run over one fractional T1 channel,
  477.       concurrently with other uses of the T1 link.  The current MIB
  478.       structure does not allow for these sorts of relationships to be
  479.       described.
  480.  
  481.  
  482.       3.1.3.  Virtual Circuits
  483.  
  484.       Several of the sub-layers for which media-specific MIB modules
  485.       have been defined are connection oriented (e.g., Frame Relay,
  486.       X.25).  Experience has shown that each effort to define such a MIB
  487.       module revisits the question of whether separate conceptual rows
  488.       in the ifTable are needed for each virtual circuit.  Most, if not
  489.       all, of these efforts to date have decided to have all virtual
  490.       circuits reference a single conceptual row in the ifTable.
  491.  
  492.  
  493.       3.1.4.  Bit and Character Oriented Interfaces
  494.  
  495.       RS-232 is an example of a character-oriented sub-layer over which
  496.       (e.g., through use of PPP) IP datagrams can be sent.  Due to the
  497.       packet-based nature of many of the objects in the ifTable,
  498.       experience has shown that it is not appropriate to have a
  499.       character-oriented sub-layer represented by a (whole) conceptual
  500.       row in the ifTable.
  501.  
  502.       Experience has also shown that it is sometimes desirable to have
  503.       some management information for bit-oriented interfaces, which are
  504.       similarly difficult to represent by a (whole) conceptual row in
  505.       the ifTable.  For example, to manage the channels of a DS1
  506.       circuit, where only some of the channels are carrying packet-based
  507.       data.
  508.  
  509.  
  510.       3.1.5.  Counter Size
  511.  
  512.  
  513.       As the speed of network media increase, the minimum time in which
  514.       a 32 bit counter will wrap decreases.  For example, on an
  515.  
  516.  
  517.  
  518.  
  519.  
  520.       Expires 26 March 1994                                     [Page 9]
  521.  
  522.  
  523.  
  524.  
  525.       Draft               Interfaces Group Evolution   26 September 1993
  526.  
  527.  
  528.       Ethernet, a stream of back-to-back, full-size packets will cause
  529.       ifInOctets to wrap in just over 57 minutes, for a T3 line, the
  530.       minimum wrap-time is just over 12 minutes, and for FDDI, it will
  531.       wrap in 5.7 minutes.  For a 1-gigabit medium, the counter might
  532.       wrap in as little as 34 seconds.  Requiring that interfaces be
  533.       polled frequently enough not to miss a counter wrap will be
  534.       increasingly problematic.
  535.  
  536.  
  537.       3.1.6.  Interface Speed
  538.  
  539.       Network speeds are increasing.  The range of ifSpeed is limited to
  540.       reporting a maximum speed of (2**31)-1 bits/second, or
  541.       approximately 2.2Gbs.  SONET defines an OC-48 interface, which is
  542.       defined at operating at 48 times 51 Mbs, which is a speed in
  543.       excess of 2.4gbits.  Thus, ifSpeed will be of diminishing utility
  544.       over the next several years.
  545.  
  546.  
  547.       3.1.7.  Multicast/Broadcast Counters
  548.  
  549.       The counters in the ifTable for packets addressed to a multicast
  550.       or the broadcast address, are combined as counters of non-unicast
  551.       packets.  In contrast, the ifExtensions MIB [7] defines one set of
  552.       counters for multicast, and a separate set for broadcast packets.
  553.       With the separate counters, the original combined counters become
  554.       redundant.
  555.  
  556.  
  557.  
  558.       3.2.  Clarifications/Revisions
  559.  
  560.       The following clarifications and/or revisions are proposed.
  561.  
  562.  
  563.       3.2.1.  Interface Numbering
  564.  
  565.       One solution to the interface numbering problem would be to
  566.       redefine ifNumber to be the largest value of ifIndex, but the
  567.       utility of such an object is questionable, and such a re-
  568.       definition would require ifNumber to be deprecated.  Thus, an
  569.       improvement would be to deprecate ifNumber and not replace it.
  570.       However, the deprecation of ifNumber would require a change to
  571.       that portion of ifIndex's definition which refers to ifNumber.
  572.       So, since the definition of ifIndex must be changed anyway in
  573.  
  574.  
  575.  
  576.  
  577.  
  578.       Expires 26 March 1994                                    [Page 10]
  579.  
  580.  
  581.  
  582.  
  583.       Draft               Interfaces Group Evolution   26 September 1993
  584.  
  585.  
  586.       order to solve the problem, changes to ifNumber do not benefit the
  587.       solution.
  588.  
  589.       The solution adopted in this memo is just to delete the
  590.       requirement that the value of ifIndex must be less than the value
  591.       of ifNumber, and to retain ifNumber with its current definition.
  592.       It could be argued that this is a change in the semantics of
  593.       ifIndex; however, all existing implementations conform to this new
  594.       definition, and in the interests of not requiring changes in
  595.       existing implementations and in the many existing media-specific
  596.       MIBs, it is proposed that this change does not require ifIndex to
  597.       be deprecated.
  598.  
  599.       This solution also results in the possibility of "holes" in the
  600.       ifTable, i.e., the ifIndex values of conceptual rows in the
  601.       ifTable are not necessarily contiguous, but SNMP's GetNext (and
  602.       SNMPv2's GetBulk) operation easily deals with such holes.  The
  603.       value of ifNumber still represents the number of conceptual rows,
  604.       which increases/decreases as new interfaces are dynamically
  605.       added/removed.  The vital constancy requirement is met by
  606.       requiring that after an interface is dynamically removed, its
  607.       ifIndex value is not re-used (by another dynamically added
  608.       interface) until after the following re-initialization of the
  609.       network management system.  This avoids the need for a priori
  610.       assignment of ifIndex values for all possible interfaces which
  611.       might be added dynamically.
  612.  
  613.       Because of the restriction of the value of ifIndex to be less than
  614.       ifNumber, interfaces have been numbered with small integer values.
  615.       This has led to the ability by humans to use the ifIndex values as
  616.       (somewhat) user-friendly names for network interfaces (e.g.,
  617.       "interface number 3").  With the relaxation of the restriction on
  618.       the value of ifIndex, there is now the possibility that ifIndex
  619.       values could be assigned as very large numbers (e.g., memory
  620.       addresses).  Such numbers would be much less user-friendly.
  621.       Therefore, this memo recommends that ifIndex values still be
  622.       assigned as small integer values starting at 1, even though the
  623.       values in use at any one time are not necessarily contiguous.
  624.       (Note that this makes remembering which values have been assigned
  625.       easy for agents which dynamically add new interfaces.)
  626.  
  627.       This proposed change introduces a new problem of its own.
  628.       Previously, there usually was a simple, direct, mapping of
  629.       interfaces to the physical ports on systems.  This mapping would
  630.       be based on the ifIndex value.  However, by removing the previous
  631.  
  632.  
  633.  
  634.  
  635.  
  636.       Expires 26 March 1994                                    [Page 11]
  637.  
  638.  
  639.  
  640.  
  641.       Draft               Interfaces Group Evolution   26 September 1993
  642.  
  643.  
  644.       restrictions on the values allowed for ifIndex, along with the
  645.       interface sub-layer concept (see the following section), mapping
  646.       from interfaces to physical ports becomes increasingly
  647.       problematic.
  648.  
  649.       To address this issue, a new object, ifName, is added to the MIB.
  650.       This object contains the device's name for the interface of which
  651.       the relevant entry in the ifTable is a component.  For example, if
  652.       a router has an interface named wan1, which is composed of PPP
  653.       running over an RS-232 port, the ifName objects for the
  654.       corresponding PPP and RS-232 entries in the ifTable will contain
  655.       the string "wan1".
  656.  
  657.  
  658.       3.2.2.  Interface Sub-Layers
  659.  
  660.       One possible but not recommended solution to the problem of
  661.       representing multiple sub-layers would be to retain the concept of
  662.       one conceptual row for all the sub-layers of an interface and have
  663.       each media-specific MIB module identify its "superior" and
  664.       "subordinate" sub-layers through OBJECT IDENTIFIER "pointers".
  665.       The drawbacks of this scheme are: 1) that the superior/subordinate
  666.       pointers are contained in the media-specific MIB modules, and
  667.       thus, a manager could not learn the structure of an interface,
  668.       without inspecting multiple pointers in different MIB modules;
  669.       this is overly complex and only possible if the manager has
  670.       knowledge of all the relevant media-specific MIB modules; 2)
  671.       current MIB modules would all need to be retrofitted with these
  672.       new "pointers"; 3) this scheme does not adequately address the
  673.       problem of upward and downward multiplexing; and 4) enumerated
  674.       values of ifType are needed for each combination of sub-layers.
  675.  
  676.       Another possible but not recommended scheme would be to retain the
  677.       concept of one conceptual row for all the sub-layers of an
  678.       interface and have a new separate MIB table to identify the
  679.       "superior" and "subordinate" sub-layers and to contain OBJECT
  680.       IDENTIFIER "pointers" to media-specific MIBs.  Effectively, one
  681.       conceptual row in the ifTable would represent each combination of
  682.       sub-layers between the internetwork-layer and the wire.  While
  683.       this scheme has fewer drawbacks, it would deprecate the use of
  684.       ifSpecific and it still does not support downward multiplexing,
  685.       such as PPP over MLP: since MLP makes two (or more) serial lines
  686.       appear to the layers above as a single physical interface, PPP
  687.       over MLP should appear to the internetwork-layer as a single
  688.       interface; this scheme, however, would result in two (or more)
  689.  
  690.  
  691.  
  692.  
  693.  
  694.       Expires 26 March 1994                                    [Page 12]
  695.  
  696.  
  697.  
  698.  
  699.       Draft               Interfaces Group Evolution   26 September 1993
  700.  
  701.  
  702.       conceptual rows in the ifTable, both of which the internetwork-
  703.       layer would run over.  This scheme also requires enumerated values
  704.       of ifType for each combination of sub-layers.
  705.  
  706.       The solution adopted in this memo is to have an individual
  707.       conceptual row in the ifTable to represent each sub-layer, and
  708.       have a new separate MIB table (the ifStackTable, see section 5 of
  709.       this memo) to identify the "superior" and "subordinate" sub-layers
  710.       through INTEGER "pointers" to the appropriate conceptual rows in
  711.       the ifTable.  This solution supports both upward and downward
  712.       multiplexing, allows the ifSpecific pointer in each conceptual row
  713.       of the ifTable to point to the media-specific MIB module for that
  714.       sub-layer, such that the new table need only be referenced to
  715.       obtain information about layering, and it only requires enumerated
  716.       values of ifType for each sub-layer, not for combinations of them.
  717.       However, it does require that the descriptions of some objects in
  718.       the ifTable (specifically, ifType, ifPhysAddress, ifInUcastPkts,
  719.       and ifOutUcastPkts) be generalized so as to apply to any sub-layer
  720.       (rather than only to a sub-layer immediately beneath the network
  721.       layer, as at present), plus some (specifically, ifSpeed) which
  722.       need to have appropriate values identified for use when a
  723.       generalized definition does not apply to a particular sub-layer.
  724.       (i.e., at some layer above) that sub-layer.
  725.  
  726.       In addition, this adopted solution makes no requirement that a
  727.       device, in which a sub-layer is instrumented by a conceptual row
  728.       of the ifTable, be aware of whether an internetwork protocol runs
  729.       on top of In fact, the counters of packets received on an
  730.       interface are defined as counting the number "delivered to a
  731.       higher-layer protocol".  This meaning of "higher-layer" includes:
  732.  
  733.       (1)  Delivery to a forwarding module which accepts
  734.            packets/frames/octets and forwards them on at the same
  735.            protocol layer.  For example, for the purposes of this
  736.            definition, the forwarding module of a MAC-layer bridge is
  737.            considered as a "higher-layer" to the MAC-layer of each port
  738.            on the bridge.
  739.  
  740.       (2)  Delivery to a a higher sub-layer within a interface stack.
  741.            For example, for the purposes of this definition, if a PPP
  742.            module operated directly over a serial interface, the PPP
  743.            module would be considered the higher sub-layer to the serial
  744.            interface.
  745.  
  746.  
  747.  
  748.  
  749.  
  750.  
  751.  
  752.       Expires 26 March 1994                                    [Page 13]
  753.  
  754.  
  755.  
  756.  
  757.       Draft               Interfaces Group Evolution   26 September 1993
  758.  
  759.  
  760.       (3)  Delivery to a a higher protocol layer which does not do
  761.            packet forwarding for sub-layers that are "at the top of" the
  762.            interface stack.  For example, for the purposes of this
  763.            definition, the local IP module would be considered the
  764.            higher layer to a SLIP serial interface.
  765.  
  766.       Similarly, for output, the counters of packets transmitted out an
  767.       interface are defined as counting the number "that higher-level
  768.       protocols requested to be transmitted".  This meaning of "higher-
  769.       layer" includes:
  770.  
  771.       (1)  A forwarding module, at the same protocol layer, which
  772.            transmits packets/frames/octets that were received on an
  773.            different interface.  For example, for the purposes of this
  774.            definition, the forwarding module of a MAC-layer bridge is
  775.            considered as a "higher-layer" to the MAC-layer of each port
  776.            on the bridge.
  777.  
  778.       (2)  The next higher sub-layer within an interface stack.  For
  779.            example, for the purposes of this definition, if a PPP module
  780.            operated directly over a serial interface, the PPP module
  781.            would be a "higher layer" to the serial interface.
  782.  
  783.       (3)  For sub-layers that are "at the top of" the interface stack,
  784.            a higher element in the network protocol stack.  For example,
  785.            for the purposes of this definition, the local IP module
  786.            would be considered the higher layer to an Ethernet
  787.            interface.
  788.  
  789.  
  790.       3.2.3.  Guidance on Defining Sub-layers
  791.  
  792.       The designer of a media-specific MIB must decide whether to divide
  793.       the interface into sub-layers or not, and if so, how to make the
  794.       divisions.  The following guidance is offered to assist the
  795.       media-specific MIB designer in these decisions.
  796.  
  797.       In general, the number of entries in the ifTable should be kept to
  798.       the minimum required for network management.  In particular, a
  799.       group of related interfaces should be treated as a single
  800.       interface with one entry in the ifTable providing that:
  801.  
  802.       (1)  None of the group of interfaces performs multiplexing for any
  803.            other interface in the agent,
  804.  
  805.  
  806.  
  807.  
  808.  
  809.  
  810.       Expires 26 March 1994                                    [Page 14]
  811.  
  812.  
  813.  
  814.  
  815.       Draft               Interfaces Group Evolution   26 September 1993
  816.  
  817.  
  818.       (2)  There is a meaningful and useful way for all of the ifTable's
  819.            information (e.g., the counters, and the status variables),
  820.            and all of the ifTable's capabilities (e.g., write access to
  821.            ifAdminStatus), to apply to the group of interfaces as a
  822.            whole.
  823.  
  824.       Under these circumstances, there should be one entry in the
  825.       ifTable for such a group of interfaces, and any internal structure
  826.       which needs to be represented to network management should be
  827.       captured in a MIB module specific to the particular type of
  828.       interface.
  829.  
  830.       Note that application of bullet 2 above to the ifTable's
  831.       ifSpecific and ifType objects requires that there is a meaningful
  832.       media-specific MIB and a meaningful ifType value which apply to
  833.       the group of interfaces as a whole.  For example, it is not
  834.       appropriate to treat an HDLC sub-layer and an RS-232 sub-layer as
  835.       a single ifTable entry when the media-specific MIBs and the ifType
  836.       values for HDLC and RS-232 are separate (rather than combined).
  837.  
  838.       Note that the sub-layers of an interface on one device will
  839.       sometimes be different to the sub-layers of the interconnected
  840.       interface of another device.  A simple example of this is a
  841.       frame-relay DTE interface which connects to a frameRelayService
  842.       interface, where the DTE interface has a different ifType value
  843.       and media-specific MIB to the DCE interface.
  844.  
  845.       These guidelines are just that, guidelines.  The designer of a
  846.       media-specific MIB is free to lay out the MIB in whatever SMI
  847.       conformant manner is desired.  However, in doing so, the media-
  848.       specific MIB MUST completely specify the sub-layering model used
  849.       for the MIB, and provide the assumptions, reasoning, and rationale
  850.       used to develop that model.
  851.  
  852.  
  853.       3.2.4.  Virtual Circuits
  854.  
  855.       This memo strongly recommends that connection-oriented sub-layers
  856.       do not have a conceptual row in the ifTable for each virtual
  857.       circuit.  This avoids the proliferation of conceptual rows,
  858.       especially those which have considerable redundant information.
  859.       (Note, as a comparison, that connection-less sub-layers do not
  860.       have conceptual rows for each remote address.)  There may,
  861.       however, be circumstances under which it is appropriate for a
  862.       virtual circuit of a connection-oriented sub-layer to have its own
  863.  
  864.  
  865.  
  866.  
  867.  
  868.       Expires 26 March 1994                                    [Page 15]
  869.  
  870.  
  871.  
  872.  
  873.       Draft               Interfaces Group Evolution   26 September 1993
  874.  
  875.  
  876.       conceptual row in the ifTable; an example of this might be PPP
  877.       over an X.25 virtual circuit.  The MIB in section 5 of this memo
  878.       supports such circumstances.
  879.  
  880.       If a media-specific MIB wishes to assign an entry in the ifTable
  881.       to each virtual circuit, the MIB designer must present the
  882.       rationale for this decision in the media-specific MIB's
  883.       specification.
  884.  
  885.  
  886.       3.2.5.  Bit and Character Oriented Interfaces
  887.  
  888.       About half the objects in the ifTable are applicable to every type
  889.       of interface: packet-oriented, character-oriented, and bit-
  890.       oriented.  Of the other half, two are applicable to both
  891.       character-oriented and packet-oriented interfaces, and the rest
  892.       are applicable only to packet-oriented interfaces.  Thus, while it
  893.       is desirable for consistency to be able to represent any/all types
  894.       of interfaces in the ifTable, it is not possible to implement the
  895.       full ifTable for bit- and character-oriented sub-layers.
  896.  
  897.       One possible but not recommended solution to this problem would be
  898.       to split the ifTable into two (or more) new MIB tables, one of
  899.       which would contain objects that are relevant only to packet-
  900.       oriented interfaces (e.g., PPP), and another that may be used by
  901.       all interfaces.  This is highly undesirable since it would require
  902.       changes in every agent implementing the ifTable (i.e., just about
  903.       every existing SNMP agent).
  904.  
  905.       The solution adopted in this memo builds upon the fact that
  906.       compliance statements in SNMPv2 (in contrast to SNMPv1) refer to
  907.       object groups, where object groups are explicitly defined by
  908.       listing the objects they contain.  Thus, in SNMPv2, multiple
  909.       compliance statements can be specified, one for all interfaces and
  910.       additional ones for specific types of interfaces.  The separate
  911.       compliance statements can be based on separate object groups,
  912.       where the object group for all interfaces can contain only those
  913.       objects from the ifTable which are appropriate for every type of
  914.       interfaces.  Using this solution, every sub-layer can have its own
  915.       conceptual row in the ifTable.
  916.  
  917.       Thus, section 5 of this memo contains definitions of the objects
  918.       of the existing 'interfaces' group of MIB-II, in a manner which is
  919.       both SNMPv2-compliant and semantically-equivalent to the existing
  920.       MIB-II definitions.  With equivalent semantics, and with the BER
  921.  
  922.  
  923.  
  924.  
  925.  
  926.       Expires 26 March 1994                                    [Page 16]
  927.  
  928.  
  929.  
  930.  
  931.       Draft               Interfaces Group Evolution   26 September 1993
  932.  
  933.  
  934.       ("on the wire") encodings unchanged, these definitions retain the
  935.       same OBJECT IDENTIFIER values as assigned by MIB-II.  Thus, in
  936.       general, no rewrite of existing agents which conform to MIB-II and
  937.       the ifExtensions MIB is required.
  938.  
  939.       Three new object groups are defined: the ifGeneralGroup containing
  940.       those objects applicable to all types of network interfaces; the
  941.       ifCharacterGroup containing those objects applicable to
  942.       character-oriented or packet-oriented network interfaces; and the
  943.       ifPacketGroup containing those objects applicable only to packet-
  944.       oriented network interfaces.
  945.  
  946.  
  947.       3.2.6.  Counter Size
  948.  
  949.       Two approaches to addressing the shrinking minimum counter-wrap
  950.       time problem were evaluated.  Counters could be scaled, for
  951.       example, ifInOctets could be changed to count received octets in,
  952.       e.g., 1024 byte blocks.  Alternatively, the size of the counter
  953.       could be increased.
  954.  
  955.       Scaling the counters was rejected.  While it provides acceptable
  956.       performance at high count rates, at low rates it suffers.  If
  957.       there is little traffic on an interface, there might be a
  958.       significant interval before enough counts occur to cause a counter
  959.       to be incremented.  Traffic would then appear to be very bursty,
  960.       leading to incorrect conclusions of the network's performance.
  961.  
  962.       The alternative, which this memo adopts, is to provide expanded,
  963.       64 bit, counters.  These counters are provided in two new groups,
  964.       the "high capacity" packet counters group (ifHCPacketGroup) and
  965.       octet counters group (ifHCCharacterGroup).  These new groups
  966.       provide new, 64 bit, counters for use as appropriate.
  967.  
  968.       The old, 32-bit, counters have not been deprecated.  The 64-bit
  969.       counters are to be used only when the 32-bit counters do not
  970.       provide enough capacity; that is, the 32 bit counters could wrap
  971.       too fast.
  972.  
  973.       For interfaces that operate at 20,000,000 (20 million) bits per
  974.       second or less, 32-bit byte and packet counters MUST be used.  For
  975.       interfaces that operate faster than 20,000,000 bits/second, and
  976.       slower than 650,000,000 bits/second, 32-bit packet counters MUST
  977.       be used and 64-bit octet counters MUST be used.  For interfaces
  978.       that operate at 650,000,000 bits/second or faster, 64-bit packet
  979.  
  980.  
  981.  
  982.  
  983.  
  984.       Expires 26 March 1994                                    [Page 17]
  985.  
  986.  
  987.  
  988.  
  989.       Draft               Interfaces Group Evolution   26 September 1993
  990.  
  991.  
  992.       counters AND 64-bit octet counters MUST be used.
  993.  
  994.       These speed steps were chosen as reasonable compromises based on
  995.       the following:
  996.  
  997.       (1)  The cost of maintaining 64-bit counters is relatively high,
  998.            so minimizing the number of agents which must support them is
  999.            desirable.  Common interfaces (such as Ethernet) should not
  1000.            require them.
  1001.  
  1002.       (2)  64-bit counters are a new feature, introduced in SNMPv2.  It
  1003.            is reasonable to expect that support for them will be spotty
  1004.            for the immediate future.  Thus, we wish to limit them to as
  1005.            few systems as possible.  This, in effect, means that 64-bit
  1006.            counters should be limited to higher speed interfaces.
  1007.            Ethernet (10,000,000 bps) and Token Ring (16,000,000 bps) are
  1008.            fairly wide-spread so it seems reasonable to not require 64-
  1009.            bit counters for these interfaces.
  1010.  
  1011.       (3)  The 32-bit octet counters will wrap in the following times,
  1012.            for the following interfaces (when transmitting maximum-sized
  1013.            packets back-to-back):
  1014.  
  1015.            -   Ethernet: 57 minutes,
  1016.  
  1017.            -   16 megabit Token Ring: 36 minutes,
  1018.  
  1019.            -   A US T3 line (45 megabits): 12 minutes,
  1020.  
  1021.            -   FDDI: 5.7 minutes
  1022.  
  1023.       (4)  The 32-bit packet counters wraps in about 57 minutes when
  1024.            64-byte packets are transmitted back-to-back on a 650,000,000
  1025.            bit/second link.
  1026.  
  1027.            As an aside, a 1-terabit (1,000 gigabits) link will cause a
  1028.            64 bit octet counter to wrap in just under 5 years.
  1029.            Conversely, an 81,000,000 terabit/second link is required to
  1030.            cause a 64-bit counter to wrap in 30 minutes.  We believe
  1031.            that, while technology rapidly marches forward, this link
  1032.            speed will not be achieved for at least several years,
  1033.            leaving sufficient time to evaluate the introduction of 96
  1034.            bit counters.
  1035.  
  1036.  
  1037.  
  1038.  
  1039.  
  1040.  
  1041.  
  1042.       Expires 26 March 1994                                    [Page 18]
  1043.  
  1044.  
  1045.  
  1046.  
  1047.       Draft               Interfaces Group Evolution   26 September 1993
  1048.  
  1049.  
  1050.       When 64-bit counters are in use, the 32-bit counters MUST still be
  1051.       available.  They will report the low 32-bits of the associated
  1052.       64-bit count (e.g., ifInOctets will report the least significant
  1053.       32 bits of ifHCInOctets).  This enhances inter-operability with
  1054.       existing implementations at a very minimal cost to agents.
  1055.  
  1056.  
  1057.       3.2.7.  Interface Speed
  1058.  
  1059.       In order to deal with increasing interface speeds, we have added
  1060.       an ifHighSpeed object.
  1061.  
  1062.       This object reports the speed of the interface in 1,000,000 (1
  1063.       million) bits/second units.  Thus, the true speed of the interface
  1064.       will be the value reported by this object, plus or minus 500,000
  1065.       bits/second.
  1066.  
  1067.       Other alternatives considered were:
  1068.  
  1069.       (1)  Making the interface speed a 64-bit gauge.  This was rejected
  1070.            since the current SMI does not allow such a syntax.
  1071.  
  1072.            Furthermore, even if 64-bit gauges were available, their use
  1073.            would require additional complexity in agents due to an
  1074.            increased requirement for 64-bit operations.
  1075.  
  1076.       (2)  We also considered making "high-32 bit" and "low-32-bit"
  1077.            objects which, when combined, would be a 64-bit value.  This
  1078.            simply seemed overly complex for what we are trying to do.
  1079.  
  1080.            Furthermore, a full 64-bits of precision does not seem
  1081.            necessary.  The value of IfHighSpeed will be the only report
  1082.            of interface speed for interfaces that are faster than
  1083.            4,294,967,295 bits per second.  At this speed, the
  1084.            granularity of ifHighSpeed will be 1,000,000 bits per second,
  1085.            thus the error will be 1/4294, or about 0.02%.  This seems
  1086.            reasonable.
  1087.  
  1088.       (3)  Adding a "scale" object, which would define the units which
  1089.            ifSpeed's value is.
  1090.  
  1091.            This would require two additional objects; one for the
  1092.            scaling object, and one to replace the current ifSpeed.  This
  1093.            later object is required since the semantics of ifSpeed would
  1094.            be significantly altered, and manager stations which do not
  1095.  
  1096.  
  1097.  
  1098.  
  1099.  
  1100.       Expires 26 March 1994                                    [Page 19]
  1101.  
  1102.  
  1103.  
  1104.  
  1105.       Draft               Interfaces Group Evolution   26 September 1993
  1106.  
  1107.  
  1108.            understand the new semantics would be confused.
  1109.  
  1110.  
  1111.       3.2.8.  Multicast/Broadcast Counters
  1112.  
  1113.       To avoid the redundancy of counting all non-unicast packets as
  1114.       well as having individual multicast and broadcast packet counters,
  1115.       we deprecate the use of the non-unicast counters, which can be
  1116.       derived from the values of the others.
  1117.  
  1118.       For the output broadcast and multicast counters defined in RFC
  1119.       1229, their definitions varied slightly from the packet counters
  1120.       in the ifTable, in that they did not count errors/discarded
  1121.       packets.  To align the definitions better, the old counters are
  1122.       deprecated and replaced by new definitions.  Counters with 64 bits
  1123.       of range are also needed, as explained above.
  1124.  
  1125.  
  1126.  
  1127.       3.2.9.  Trap Enable
  1128.  
  1129.       In the multi-layer interface model, each sub-layer for which there
  1130.       is an entry in the ifTable can generate linkUp/Down Traps.  Since
  1131.       interface state changes would tend to propagate through the
  1132.       interface (from top to bottom, or bottom to top), it is likely
  1133.       that several traps would be generated for each linkUp/Down
  1134.       occurrence.
  1135.  
  1136.       It is desirable to provide a mechanism for manager stations to
  1137.       control the generation of these traps.  To this end, the
  1138.       ifLinkUpDownTrapEnable object has been added.  This object allows
  1139.       managers to limit generation of traps to just the sub-layers of
  1140.       interest.
  1141.  
  1142.       The default setting should limit the number of traps generated to
  1143.       one per interface per linkUp/Down event.  Furthermore, it seems
  1144.       that the conditions that cause these state changes that are of
  1145.       most interest to network managers occur at the lowest level of an
  1146.       interface stack.  Therefore we specify that by default, only the
  1147.       lowest sub-layer of the interface generate traps.
  1148.  
  1149.  
  1150.  
  1151.  
  1152.  
  1153.  
  1154.  
  1155.  
  1156.  
  1157.  
  1158.       Expires 26 March 1994                                    [Page 20]
  1159.  
  1160.  
  1161.  
  1162.  
  1163.       Draft               Interfaces Group Evolution   26 September 1993
  1164.  
  1165.  
  1166.       3.3.  Media-Specific MIB Applicability
  1167.  
  1168.       The exact use and semantics of many objects in this MIB are open
  1169.       to some interpretation.  This is a result of the generic nature of
  1170.       this MIB.  It is not always possible to come up with specific,
  1171.       unambiguous, text that covers all cases and yet preserve the
  1172.       generic nature of the MIB.
  1173.  
  1174.       Therefore, it is incumbent upon a media-specific MIB designer to,
  1175.       wherever necessary, clarify the use of the objects in this MIB
  1176.       with respect to the media-specific MIB.
  1177.  
  1178.       Specific areas of clarification include
  1179.  
  1180.       Layering Model
  1181.            The media-specific MIB designer MUST completely and
  1182.            unambiguously specify the layering model used.  Each
  1183.            individual sub-layer must be identified.
  1184.  
  1185.       Virtual Circuits
  1186.            The media-specific MIB designer MUST specify whether virtual
  1187.            circuits are assigned entries in the ifTable or not.  If they
  1188.            are, compelling rationale must be presented.
  1189.  
  1190.       ifTestTable
  1191.            The media-specific MIB designer MUST specify the
  1192.            applicability of the ifTestTable.
  1193.  
  1194.       ifRcvAddressTable
  1195.            The media-specific MIB designer MUST specify the
  1196.            applicability of the ifRcvAddressTable.
  1197.  
  1198.       ifSpecific
  1199.            The media-specific MIB must specify, for each of the ifType
  1200.            values to which it applies, the instance of a MIB object to
  1201.            which ifSpecific should point.
  1202.  
  1203.       However, wherever this interface MIB is specific in the semantics,
  1204.       DESCRIPTION, or applicability of objects, the media-specific MIB
  1205.       designer MUST NOT change said semantics, DESCRIPTION, or
  1206.       applicability.
  1207.  
  1208.  
  1209.  
  1210.  
  1211.  
  1212.  
  1213.  
  1214.  
  1215.  
  1216.       Expires 26 March 1994                                    [Page 21]
  1217.  
  1218.  
  1219.  
  1220.  
  1221.       Draft               Interfaces Group Evolution   26 September 1993
  1222.  
  1223.  
  1224.       4.  Overview
  1225.  
  1226.       This MIB consists of 5 tables:
  1227.  
  1228.       ifTable
  1229.            This table is the ifTable from MIB-II.
  1230.  
  1231.       ifXTable
  1232.            This table contains objects that have been added to the
  1233.            Interface MIB as a result of the Interface Evolution effort,
  1234.            or replacements for objects of the original, MIB-II, ifTable
  1235.            that were deprecated because the semantics of said objects
  1236.            have significantly changed.  This table also contains objects
  1237.            that were previously in the ifExtnsTable.
  1238.  
  1239.       ifStackTable
  1240.            This table contains objects that define the relationships
  1241.            among the sub-layers of an interface.
  1242.  
  1243.       ifTestTable
  1244.            This table contains objects that are used to perform tests on
  1245.            interfaces.  This table is a generic table.  The designers of
  1246.            media-specific MIBs must define exactly how this table
  1247.            applies to their specific MIB.
  1248.  
  1249.            This table replaces the interface test table defined in
  1250.            RFC1229 [7].  The significant change is the replacement of
  1251.            the ifExtnsTestCommunity (and ifExtnsTestContext which would
  1252.            also have been required for SNMPv2) and ifExtnsTestRequestId
  1253.            objects, by the new ifTestId, ifTestStatus, and ifTestOwner
  1254.            objects.
  1255.  
  1256.       ifRcvAddressTable
  1257.            This table contains objects that are used to define the
  1258.            media-level addresses which this interface will receive.
  1259.            This table is a generic table.  The designers of media-
  1260.            specific MIBs must define exactly how this table applies to
  1261.            their specific MIB.
  1262.  
  1263.  
  1264.  
  1265.  
  1266.  
  1267.  
  1268.  
  1269.  
  1270.  
  1271.  
  1272.  
  1273.  
  1274.       Expires 26 March 1994                                    [Page 22]
  1275.  
  1276.  
  1277.  
  1278.  
  1279.       Draft               Interfaces Group Evolution   26 September 1993
  1280.  
  1281.  
  1282.       5.  Definitions
  1283.  
  1284.       IF-MIB DEFINITIONS ::= BEGIN
  1285.  
  1286.       IMPORTS
  1287.           MODULE-IDENTITY, OBJECT-TYPE, Counter32, Gauge32,
  1288.           Integer32, TimeTicks, experimental       FROM SNMPv2-SMI
  1289.           DisplayString, PhysAddress, TruthValue,
  1290.           RowStatus, AutonomousType, TestAndIncr   FROM SNMPv2-TC
  1291.           MODULE-COMPLIANCE, OBJECT-GROUP          FROM SNMPv2-CONF
  1292.           interfaces                               FROM RFC-1213;
  1293.  
  1294.  
  1295.       ifMIB MODULE-IDENTITY
  1296.           LAST-UPDATED "9309262355Z"
  1297.           ORGANIZATION "IETF Interfaces MIB Working Group"
  1298.           CONTACT-INFO
  1299.                   "   Keith McCloghrie
  1300.                       Hughes LAN Systems
  1301.                       1225 Charleston Road, Mountain View, Ca. 94043
  1302.                       415-966-7934
  1303.                       kzm@hls.com
  1304.  
  1305.                       Frank Kastenholz
  1306.                       FTP Software
  1307.                       2 High Street, North Andover, Mass. 01845
  1308.                       (508)685-4000
  1309.                       kasten@ftp.com"
  1310.           DESCRIPTION
  1311.                   "The MIB module to describe generic objects for
  1312.                   network interface sub-layers.  This MIB is an updated
  1313.                   version of MIB-II's ifTable, and incorporates the
  1314.                   extensions defined in RFC 1229."
  1315.           ::= { experimental xx }
  1316.  
  1317.       ifMIBObjects OBJECT IDENTIFIER ::= { ifMIB 1 }
  1318.  
  1319.  
  1320.  
  1321.  
  1322.  
  1323.  
  1324.  
  1325.  
  1326.  
  1327.  
  1328.  
  1329.  
  1330.  
  1331.  
  1332.       Expires 26 March 1994                                    [Page 23]
  1333.  
  1334.  
  1335.  
  1336.  
  1337.       Draft               Interfaces Group Evolution   26 September 1993
  1338.  
  1339.  
  1340.       -- OwnerString has the same semantics as used in RFC 1271
  1341.  
  1342.       OwnerString ::= TEXTUAL-CONVENTION
  1343.           DISPLAY-HINT "255a"
  1344.           STATUS       current
  1345.           DESCRIPTION
  1346.                   "This data type is used to model an administratively
  1347.                   assigned name of the owner of a resource.  This
  1348.                   information is taken from the NVT ASCII character set.
  1349.                   It is suggested that this name contain one or more of
  1350.                   the following: ASCII form of the manager station's
  1351.                   transport address, management station name (e.g.,
  1352.                   domain name), network management personnel's name,
  1353.                   location, or phone number.  In some cases the agent
  1354.                   itself will be the owner of an entry.  In these cases,
  1355.                   this string shall be set to a string starting with
  1356.                   'agent'."
  1357.           SYNTAX       OCTET STRING (SIZE(0..255))
  1358.  
  1359.  
  1360.  
  1361.  
  1362.  
  1363.  
  1364.  
  1365.  
  1366.  
  1367.  
  1368.  
  1369.  
  1370.  
  1371.  
  1372.  
  1373.  
  1374.  
  1375.  
  1376.  
  1377.  
  1378.  
  1379.  
  1380.  
  1381.  
  1382.  
  1383.  
  1384.  
  1385.  
  1386.  
  1387.  
  1388.  
  1389.  
  1390.       Expires 26 March 1994                                    [Page 24]
  1391.  
  1392.  
  1393.  
  1394.  
  1395.       Draft               Interfaces Group Evolution   26 September 1993
  1396.  
  1397.  
  1398.       ifNumber  OBJECT-TYPE
  1399.           SYNTAX      Integer32
  1400.           MAX-ACCESS  read-only
  1401.           STATUS      current
  1402.           DESCRIPTION
  1403.                   "The number of network interfaces (regardless of their
  1404.                   current state) present on this system."
  1405.           ::= { interfaces 1 }
  1406.  
  1407.  
  1408.       -- the Interfaces table
  1409.  
  1410.       -- The Interfaces table contains information on the entity's
  1411.       -- interfaces.  Each sub-layer below the internetwork-layer
  1412.       -- of a network interface is considered to be an interface.
  1413.  
  1414.       ifTable OBJECT-TYPE
  1415.           SYNTAX      SEQUENCE OF IfEntry
  1416.           MAX-ACCESS  not-accessible
  1417.           STATUS      current
  1418.           DESCRIPTION
  1419.                   "A list of interface entries.  The number of entries
  1420.                   is given by the value of ifNumber."
  1421.           ::= { interfaces 2 }
  1422.  
  1423.       ifEntry OBJECT-TYPE
  1424.           SYNTAX      IfEntry
  1425.           MAX-ACCESS  not-accessible
  1426.           STATUS      current
  1427.           DESCRIPTION
  1428.                   "An entry containing management information applicable
  1429.                   to a particular interface."
  1430.           INDEX   { ifIndex }
  1431.           ::= { ifTable 1 }
  1432.  
  1433.       IfEntry ::=
  1434.           SEQUENCE {
  1435.               ifIndex                 Integer32,
  1436.               ifDescr                 DisplayString,
  1437.               ifType                  INTEGER,
  1438.               ifMtu                   Integer32,
  1439.               ifSpeed                 Gauge32,
  1440.               ifPhysAddress           PhysAddress,
  1441.               ifAdminStatus           INTEGER,
  1442.               ifOperStatus            INTEGER,
  1443.  
  1444.  
  1445.  
  1446.  
  1447.  
  1448.       Expires 26 March 1994                                    [Page 25]
  1449.  
  1450.  
  1451.  
  1452.  
  1453.       Draft               Interfaces Group Evolution   26 September 1993
  1454.  
  1455.  
  1456.               ifLastChange            TimeTicks,
  1457.               ifInOctets              Counter32,
  1458.               ifInUcastPkts           Counter32,
  1459.               ifInNUcastPkts          Counter32,  -- deprecated
  1460.               ifInDiscards            Counter32,
  1461.               ifInErrors              Counter32,
  1462.               ifInUnknownProtos       Counter32,
  1463.               ifOutOctets             Counter32,
  1464.               ifOutUcastPkts          Counter32,
  1465.               ifOutNUcastPkts         Counter32,  -- deprecated
  1466.               ifOutDiscards           Counter32,
  1467.               ifOutErrors             Counter32,
  1468.               ifOutQLen               Gauge32,    -- deprecated
  1469.               ifSpecific              OBJECT IDENTIFIER
  1470.           }
  1471.  
  1472.  
  1473.       ifIndex OBJECT-TYPE
  1474.           SYNTAX      Integer32
  1475.           MAX-ACCESS  read-only
  1476.           STATUS      current
  1477.           DESCRIPTION
  1478.                   "A unique value, greater than zero, for each
  1479.                   interface.  It is recommended that values are assigned
  1480.                   contiguously starting from 1.  The value for each
  1481.                   interface sub-layer must remain constant at least from
  1482.                   one re-initialization of the entity's network
  1483.                   management system to the next re-initialization."
  1484.           ::= { ifEntry 1 }
  1485.  
  1486.       ifDescr OBJECT-TYPE
  1487.           SYNTAX      DisplayString (SIZE (0..255))
  1488.           MAX-ACCESS  read-only
  1489.           STATUS      current
  1490.           DESCRIPTION
  1491.                   "A textual string containing information about the
  1492.                   interface.  This string should include the name of the
  1493.                   manufacturer, the product name and the version of the
  1494.                   interface hardware/software."
  1495.           ::= { ifEntry 2 }
  1496.  
  1497.       ifType OBJECT-TYPE
  1498.           SYNTAX  INTEGER {
  1499.                       other(1),          -- none of the following
  1500.                       regular1822(2),
  1501.  
  1502.  
  1503.  
  1504.  
  1505.  
  1506.       Expires 26 March 1994                                    [Page 26]
  1507.  
  1508.  
  1509.  
  1510.  
  1511.       Draft               Interfaces Group Evolution   26 September 1993
  1512.  
  1513.  
  1514.                       hdh1822(3),
  1515.                       ddn-x25(4),
  1516.                       rfc877-x25(5),
  1517.                       ethernet-csmacd(6),
  1518.                       iso88023-csmacd(7),
  1519.                       iso88024-tokenBus(8),
  1520.                       iso88025-tokenRing(9),
  1521.                       iso88026-man(10),
  1522.                       starLan(11),
  1523.                       proteon-10Mbit(12),
  1524.                       proteon-80Mbit(13),
  1525.                       hyperchannel(14),
  1526.                       fddi(15),
  1527.                       lapb(16),
  1528.                       sdlc(17),
  1529.                       ds1(18),           -- DS1/E1 (RFC 1406)
  1530.                       e1(19),            -- obsolete
  1531.                       basicISDN(20),
  1532.                       primaryISDN(21),
  1533.                                           -- proprietary serial
  1534.                       propPointToPointSerial(22),
  1535.                       ppp(23),
  1536.                       softwareLoopback(24),
  1537.                       eon(25),            -- CLNP over IP (RFC 1070)
  1538.                       ethernet-3Mbit(26),
  1539.                       nsip(27),           -- XNS over IP
  1540.                       slip(28),           -- generic SLIP
  1541.                       ultra(29),          -- ULTRA technologies
  1542.                       ds3(30),            -- T-3
  1543.                       sip(31),            -- SMDS
  1544.                       frame-relay(32),    -- DTE only
  1545.                       rs232(33),
  1546.                       para(34),           -- parallel-port
  1547.                       arcnet(35),         -- arcnet
  1548.                       arcnetPlus(36),     -- arcnet plus
  1549.                       atm(37),            -- ATM cells
  1550.                       miox25(38),
  1551.                       sonet(39),          -- SONET or SDH
  1552.                       x25ple(40),
  1553.                       iso88022llc(41),
  1554.                       localTalk(42),
  1555.                       smds-dxi(43),
  1556.                       frameRelayService(44),  -- Frame relay DCE
  1557.                       v35(45),
  1558.                       hssi(46),
  1559.  
  1560.  
  1561.  
  1562.  
  1563.  
  1564.       Expires 26 March 1994                                    [Page 27]
  1565.  
  1566.  
  1567.  
  1568.  
  1569.       Draft               Interfaces Group Evolution   26 September 1993
  1570.  
  1571.  
  1572.                       hippi(47),
  1573.                       modem(48),          -- Generic modem
  1574.                       aal5(49)            -- AAL5 over ATM
  1575.                   }
  1576.           MAX-ACCESS  read-only
  1577.           STATUS      current
  1578.           DESCRIPTION
  1579.                   "The type of interface.  Additional values for ifType
  1580.                   are assigned by the Internet Assigned Numbers
  1581.                   Authority (IANA).  Newly assigned ifType values are
  1582.                   published periodically by IANA in either the Assigned
  1583.                   Numbers RFC, or some derivative of it specific to
  1584.                   Internet Network Management number assignments.  (The
  1585.                   latest arrangements can be obtained by contacting the
  1586.                   IANA.)
  1587.  
  1588.                   Requests for new values should be made to IANA via
  1589.                   email (iana@isi.edu).
  1590.  
  1591.                   The relationship between the assignment of ifType
  1592.                   values and of OIDs to particular media-specific MIBs
  1593.                   is solely the purview of IANA and is subject to change
  1594.                   without notice.  Quite often, a media-specific MIB's
  1595.                   OID-subtree assignment within MIB-II's 'transmission'
  1596.                   subtree will be the same as its ifType value.
  1597.                   However, in some circumstances this will not be the
  1598.                   case, and implementors must not pre-assume any
  1599.                   specific relationship between ifType values and
  1600.                   transmission subtree OIDs."
  1601.           ::= { ifEntry 3 }
  1602.  
  1603.       ifMtu OBJECT-TYPE
  1604.           SYNTAX      Integer32
  1605.           MAX-ACCESS  read-only
  1606.           STATUS      current
  1607.           DESCRIPTION
  1608.                   "The size of the largest packet which can be
  1609.                   sent/received on the interface, specified in octets.
  1610.                   For interfaces that are used for transmitting network
  1611.                   datagrams, this is the size of the largest network
  1612.                   datagram that can be sent on the interface."
  1613.           ::= { ifEntry 4 }
  1614.  
  1615.       ifSpeed OBJECT-TYPE
  1616.           SYNTAX      Gauge32
  1617.  
  1618.  
  1619.  
  1620.  
  1621.  
  1622.       Expires 26 March 1994                                    [Page 28]
  1623.  
  1624.  
  1625.  
  1626.  
  1627.       Draft               Interfaces Group Evolution   26 September 1993
  1628.  
  1629.  
  1630.           MAX-ACCESS  read-only
  1631.           STATUS      current
  1632.           DESCRIPTION
  1633.                   "An estimate of the interface's current bandwidth in
  1634.                   bits per second.  For interfaces which do not vary in
  1635.                   bandwidth or for those where no accurate estimation
  1636.                   can be made, this object should contain the nominal
  1637.                   bandwidth.  If the bandwidth of the interface is
  1638.                   greater than the maximum value reportable by this
  1639.                   object then this object should report its maximum
  1640.                   value (4,294,967,295) and ifHighSpeed must be used to
  1641.                   report the interace's speed.  For a sub-layer which
  1642.                   has no concept of bandwidth, this object should be
  1643.                   zero."
  1644.           ::= { ifEntry 5 }
  1645.  
  1646.       ifPhysAddress OBJECT-TYPE
  1647.           SYNTAX      PhysAddress
  1648.           MAX-ACCESS  read-only
  1649.           STATUS      current
  1650.           DESCRIPTION
  1651.                   "The interface's address at its protocol sub-layer.
  1652.                   The interface's media-specific MIB must define the bit
  1653.                   and byte ordering and format of the value contained by
  1654.                   this object.  For interfaces which do not have such an
  1655.                   address (e.g., a serial line), this object should
  1656.                   contain an octet string of zero length."
  1657.           ::= { ifEntry 6 }
  1658.  
  1659.       ifAdminStatus OBJECT-TYPE
  1660.           SYNTAX  INTEGER {
  1661.                       up(1),       -- ready to pass packets
  1662.                       down(2),
  1663.                       testing(3)   -- in some test mode
  1664.                   }
  1665.           MAX-ACCESS  read-write
  1666.           STATUS      current
  1667.           DESCRIPTION
  1668.                   "The desired state of the interface.  The testing(3)
  1669.                   state indicates that no operational packets can be
  1670.                   passed."
  1671.           ::= { ifEntry 7 }
  1672.  
  1673.       ifOperStatus OBJECT-TYPE
  1674.           SYNTAX  INTEGER {
  1675.  
  1676.  
  1677.  
  1678.  
  1679.  
  1680.       Expires 26 March 1994                                    [Page 29]
  1681.  
  1682.  
  1683.  
  1684.  
  1685.       Draft               Interfaces Group Evolution   26 September 1993
  1686.  
  1687.  
  1688.                       up(1),       -- ready to pass packets
  1689.                       down(2),
  1690.                       testing(3),  -- in some test mode
  1691.                       unknown(4)   -- status can not be determined
  1692.                                    -- for some reason.
  1693.                   }
  1694.           MAX-ACCESS  read-only
  1695.           STATUS      current
  1696.           DESCRIPTION
  1697.                   "The current operational state of the interface.  The
  1698.                   testing(3) state indicates that no operational packets
  1699.                   can be passed."
  1700.           ::= { ifEntry 8 }
  1701.  
  1702.       ifLastChange OBJECT-TYPE
  1703.           SYNTAX      TimeTicks
  1704.           MAX-ACCESS  read-only
  1705.           STATUS      current
  1706.           DESCRIPTION
  1707.                   "The value of sysUpTime at the time the interface
  1708.                   entered its current operational state.  If the current
  1709.                   state was entered prior to the last re-initialization
  1710.                   of the local network management subsystem, then this
  1711.                   object contains a zero value."
  1712.           ::= { ifEntry 9 }
  1713.  
  1714.       ifInOctets OBJECT-TYPE
  1715.           SYNTAX      Counter32
  1716.           MAX-ACCESS  read-only
  1717.           STATUS      current
  1718.           DESCRIPTION
  1719.                   "The total number of octets received on the interface,
  1720.                   including framing characters."
  1721.           ::= { ifEntry 10 }
  1722.  
  1723.       ifInUcastPkts OBJECT-TYPE
  1724.           SYNTAX      Counter32
  1725.           MAX-ACCESS  read-only
  1726.           STATUS      current
  1727.           DESCRIPTION
  1728.                   "The number of packets, delivered by this sub-layer to
  1729.                   a higher (sub-)layer, which were not addressed to a
  1730.                   multicast or broadcast address at this sub-layer."
  1731.           ::= { ifEntry 11 }
  1732.  
  1733.  
  1734.  
  1735.  
  1736.  
  1737.  
  1738.       Expires 26 March 1994                                    [Page 30]
  1739.  
  1740.  
  1741.  
  1742.  
  1743.       Draft               Interfaces Group Evolution   26 September 1993
  1744.  
  1745.  
  1746.       ifInNUcastPkts OBJECT-TYPE
  1747.           SYNTAX  Counter32
  1748.           MAX-ACCESS  read-only
  1749.           STATUS      deprecated
  1750.           DESCRIPTION
  1751.                   "The number of packets, delivered by this sub-layer to
  1752.                   a higher (sub-)layer, which were addressed to a
  1753.                   multicast or broadcast address at this sub-layer.
  1754.  
  1755.                   This object is deprecated in favour of
  1756.                   ifInMulticastPkts and ifInBroadcastPkts."
  1757.           ::= { ifEntry 12 }
  1758.  
  1759.       ifInDiscards OBJECT-TYPE
  1760.           SYNTAX      Counter32
  1761.           MAX-ACCESS  read-only
  1762.           STATUS      current
  1763.           DESCRIPTION
  1764.                   "The number of inbound packets which were chosen to be
  1765.                   discarded even though no errors had been detected to
  1766.                   prevent their being deliverable to a higher-layer
  1767.                   protocol.  One possible reason for discarding such a
  1768.                   packet could be to free up buffer space."
  1769.           ::= { ifEntry 13 }
  1770.  
  1771.       ifInErrors OBJECT-TYPE
  1772.           SYNTAX      Counter32
  1773.           MAX-ACCESS  read-only
  1774.           STATUS      current
  1775.           DESCRIPTION
  1776.                   "The number of inbound packets that contained errors
  1777.                   preventing them from being deliverable to a higher-
  1778.                   layer protocol."
  1779.           ::= { ifEntry 14 }
  1780.  
  1781.       ifInUnknownProtos OBJECT-TYPE
  1782.           SYNTAX      Counter32
  1783.           MAX-ACCESS  read-only
  1784.           STATUS      current
  1785.           DESCRIPTION
  1786.                   "The number of packets received via the interface
  1787.                   which were discarded because of an unknown or
  1788.                   unsupported protocol."
  1789.           ::= { ifEntry 15 }
  1790.  
  1791.  
  1792.  
  1793.  
  1794.  
  1795.  
  1796.       Expires 26 March 1994                                    [Page 31]
  1797.  
  1798.  
  1799.  
  1800.  
  1801.       Draft               Interfaces Group Evolution   26 September 1993
  1802.  
  1803.  
  1804.       ifOutOctets OBJECT-TYPE
  1805.           SYNTAX      Counter32
  1806.           MAX-ACCESS  read-only
  1807.           STATUS      current
  1808.           DESCRIPTION
  1809.                   "The total number of octets transmitted out of the
  1810.                   interface, including framing characters."
  1811.           ::= { ifEntry 16 }
  1812.  
  1813.       ifOutUcastPkts OBJECT-TYPE
  1814.           SYNTAX      Counter32
  1815.           MAX-ACCESS  read-only
  1816.           STATUS      current
  1817.           DESCRIPTION
  1818.                   "The total number of packets that higher-level
  1819.                   protocols requested be transmitted, and which were not
  1820.                   addressed to a multicast or broadcast address at this
  1821.                   sub-layer, including those that were discarded or not
  1822.                   sent."
  1823.           ::= { ifEntry 17 }
  1824.  
  1825.       ifOutNUcastPkts OBJECT-TYPE
  1826.           SYNTAX      Counter32
  1827.           MAX-ACCESS  read-only
  1828.           STATUS      deprecated
  1829.           DESCRIPTION
  1830.                   "The total number of packets that higher-level
  1831.                   protocols requested be transmitted, and which were
  1832.                   addressed to a multicast or broadcast address at this
  1833.                   sub-layer, including those that were discarded or not
  1834.                   sent.
  1835.  
  1836.                   This object is deprecated in favour of
  1837.                   ifOutMulticastPkts and ifOutBroadcastPkts."
  1838.           ::= { ifEntry 18 }
  1839.  
  1840.       ifOutDiscards OBJECT-TYPE
  1841.           SYNTAX      Counter32
  1842.           MAX-ACCESS  read-only
  1843.           STATUS      current
  1844.           DESCRIPTION
  1845.                   "The number of outbound packets which were chosen to
  1846.                   be discarded even though no errors had been detected
  1847.                   to prevent their being transmitted.  One possible
  1848.                   reason for discarding such a packet could be to free
  1849.  
  1850.  
  1851.  
  1852.  
  1853.  
  1854.       Expires 26 March 1994                                    [Page 32]
  1855.  
  1856.  
  1857.  
  1858.  
  1859.       Draft               Interfaces Group Evolution   26 September 1993
  1860.  
  1861.  
  1862.                   up buffer space."
  1863.           ::= { ifEntry 19 }
  1864.  
  1865.       ifOutErrors OBJECT-TYPE
  1866.           SYNTAX      Counter32
  1867.           MAX-ACCESS  read-only
  1868.           STATUS      current
  1869.           DESCRIPTION
  1870.                   "The number of outbound packets that could not be
  1871.                   transmitted because of errors."
  1872.           ::= { ifEntry 20 }
  1873.  
  1874.       ifOutQLen OBJECT-TYPE
  1875.           SYNTAX      Gauge32
  1876.           MAX-ACCESS  read-only
  1877.           STATUS      deprecated
  1878.           DESCRIPTION
  1879.                   "The length of the output packet queue (in packets)."
  1880.           ::= { ifEntry 21 }
  1881.  
  1882.       ifSpecific OBJECT-TYPE
  1883.           SYNTAX      OBJECT IDENTIFIER
  1884.           MAX-ACCESS  read-only
  1885.           STATUS      current
  1886.           DESCRIPTION
  1887.                   "A reference to MIB definitions specific to the
  1888.                   particular media being used to realize the interface.
  1889.                   It is recommended that this value point to an instance
  1890.                   of a MIB object in the media-specific MIB, i.e., that
  1891.                   this object have the semantics associated with the
  1892.                   InstancePointer textual convention defined in RFC
  1893.                   1443.  In fact, it is recommended that the media-
  1894.                   specific MIB specify what value ifSpecific should/can
  1895.                   take for values of ifType.  If no MIB definitions
  1896.                   specific to the particular media are available, the
  1897.                   value should be set to the OBJECT IDENTIFIER { 0 0 }."
  1898.           ::= { ifEntry 22 }
  1899.  
  1900.  
  1901.  
  1902.  
  1903.  
  1904.  
  1905.  
  1906.  
  1907.  
  1908.  
  1909.  
  1910.  
  1911.  
  1912.       Expires 26 March 1994                                    [Page 33]
  1913.  
  1914.  
  1915.  
  1916.  
  1917.       Draft               Interfaces Group Evolution   26 September 1993
  1918.  
  1919.  
  1920.       --
  1921.       --   Extension to the interface table
  1922.       --
  1923.       -- This table replaces the ifExtnsTable table.
  1924.       --
  1925.  
  1926.       ifXTable        OBJECT-TYPE
  1927.           SYNTAX      SEQUENCE OF IfXEntry
  1928.           MAX-ACCESS  not-accessible
  1929.           STATUS      current
  1930.           DESCRIPTION
  1931.                   "A list of interface entries.  The number of entries
  1932.                   is given by the value of ifNumber.  This table
  1933.                   contains additional objects for the interface table."
  1934.           ::= { ifMIBObjects 1 }
  1935.  
  1936.       ifXEntry        OBJECT-TYPE
  1937.           SYNTAX      IfXEntry
  1938.           MAX-ACCESS  not-accessible
  1939.           STATUS      current
  1940.           DESCRIPTION
  1941.                   "An entry containing additional management information
  1942.                   applicable to a particular interface."
  1943.           AUGMENTS    { ifEntry }
  1944.           ::= { ifXTable 1 }
  1945.  
  1946.       IfXEntry ::=
  1947.           SEQUENCE {
  1948.               ifName                  DisplayString,
  1949.               ifInMulticastPkts       Counter32,
  1950.               ifInBroadcastPkts       Counter32,
  1951.               ifOutMulticastPkts      Counter32,
  1952.               ifOutBroadcastPkts      Counter32,
  1953.               ifHCInOctets            Counter64,
  1954.               ifHCInUcastPkts         Counter64,
  1955.               ifHCInMulticastPkts     Counter64,
  1956.               ifHCInBroadcastPkts     Counter64,
  1957.               ifHCOutOctets           Counter64,
  1958.               ifHCOutUcastPkts        Counter64,
  1959.               ifHCOutMulticastPkts    Counter64,
  1960.               ifHCOutBroadcastPkts    Counter64,
  1961.               ifLinkUpDownTrapEnable  INTEGER,
  1962.               ifHighSpeed             Gauge32,
  1963.               ifPromiscuousMode       TruthValue
  1964.           }
  1965.  
  1966.  
  1967.  
  1968.  
  1969.  
  1970.       Expires 26 March 1994                                    [Page 34]
  1971.  
  1972.  
  1973.  
  1974.  
  1975.       Draft               Interfaces Group Evolution   26 September 1993
  1976.  
  1977.  
  1978.       ifName OBJECT-TYPE
  1979.           SYNTAX      DisplayString
  1980.           MAX-ACCESS  read-only
  1981.           STATUS      current
  1982.           DESCRIPTION
  1983.                   "The textual name of the interface.  The value of this
  1984.                   object should be the name of the interface as assigned
  1985.                   by the local device and should be suitable for use in
  1986.                   commands entered at the device's `console'.  This
  1987.                   might be a text name, such as `le0' or a simple port
  1988.                   number, such as `1', depending on the interface naming
  1989.                   syntax of the device.  If several entries in the
  1990.                   ifTable together represent a single interface as named
  1991.                   by the device, then each will have the same value of
  1992.                   ifName.  If there is no local name, or this object is
  1993.                   otherwise not applicable, then this object contains a
  1994.                   0-length string."
  1995.           ::= { ifXEntry 1 }
  1996.  
  1997.       ifInMulticastPkts OBJECT-TYPE
  1998.           SYNTAX      Counter32
  1999.           MAX-ACCESS  read-only
  2000.           STATUS      current
  2001.           DESCRIPTION
  2002.                   "The number of packets, delivered by this sub-layer to
  2003.                   a higher (sub-)layer, which were addressed to a
  2004.                   multicast address at this sub-layer.  For a MAC layer
  2005.                   protocol, this includes both Group and Functional
  2006.                   addresses."
  2007.           ::= { ifXEntry 2 }
  2008.  
  2009.       ifInBroadcastPkts OBJECT-TYPE
  2010.           SYNTAX      Counter32
  2011.           MAX-ACCESS  read-only
  2012.           STATUS      current
  2013.           DESCRIPTION
  2014.                   "The number of packets, delivered by this sub-layer to
  2015.                   a higher (sub-)layer, which were addressed to a
  2016.                   broadcast address at this sub-layer."
  2017.           ::= { ifXEntry 3 }
  2018.  
  2019.       ifOutMulticastPkts OBJECT-TYPE
  2020.           SYNTAX      Counter32
  2021.           MAX-ACCESS  read-only
  2022.           STATUS      current
  2023.  
  2024.  
  2025.  
  2026.  
  2027.  
  2028.       Expires 26 March 1994                                    [Page 35]
  2029.  
  2030.  
  2031.  
  2032.  
  2033.       Draft               Interfaces Group Evolution   26 September 1993
  2034.  
  2035.  
  2036.           DESCRIPTION
  2037.                   "The total number of packets that higher-level
  2038.                   protocols requested be transmitted, and which were
  2039.                   addressed to a multicast address at this sub-layer,
  2040.                   including those that were discarded or not sent.  For
  2041.                   a MAC layer protocol, this includes both Group and
  2042.                   Functional addresses."
  2043.           ::= { ifXEntry 4 }
  2044.  
  2045.       ifOutBroadcastPkts OBJECT-TYPE
  2046.           SYNTAX      Counter32
  2047.           MAX-ACCESS  read-only
  2048.           STATUS      current
  2049.           DESCRIPTION
  2050.                   "The total number of packets that higher-level
  2051.                   protocols requested be transmitted, and which were
  2052.                   addressed to a broadcast address at this sub-layer,
  2053.                   including those that were discarded or not sent."
  2054.           ::= { ifXEntry 5 }
  2055.  
  2056.       --
  2057.       -- High Capacity Counter objects.  These objects are all
  2058.       -- 64 bit versions of the "basic" ifTable counters.  These
  2059.       -- objects all have the same basic semantics as their 32-bit
  2060.       -- counterparts, however, their syntax has been extended
  2061.       -- to 64 bits.
  2062.       --
  2063.  
  2064.       ifHCInOctets OBJECT-TYPE
  2065.           SYNTAX      Counter64
  2066.           MAX-ACCESS  read-only
  2067.           STATUS      current
  2068.           DESCRIPTION
  2069.                   "The total number of octets received on the interface,
  2070.                   including framing characters.  This object is a 64-bit
  2071.                   version of ifInOctets."
  2072.           ::= { ifXEntry 6 }
  2073.  
  2074.       ifHCInUcastPkts OBJECT-TYPE
  2075.           SYNTAX      Counter64
  2076.           MAX-ACCESS  read-only
  2077.           STATUS      current
  2078.           DESCRIPTION
  2079.                   "The number of packets, delivered by this sub-layer to
  2080.                   a higher (sub-)layer, which were not addressed to a
  2081.  
  2082.  
  2083.  
  2084.  
  2085.  
  2086.       Expires 26 March 1994                                    [Page 36]
  2087.  
  2088.  
  2089.  
  2090.  
  2091.       Draft               Interfaces Group Evolution   26 September 1993
  2092.  
  2093.  
  2094.                   multicast or broadcast address at this sub-layer.
  2095.                   This object is a 64-bit version of ifInUcastPkts."
  2096.           ::= { ifXEntry 7 }
  2097.  
  2098.       ifHCInMulticastPkts OBJECT-TYPE
  2099.           SYNTAX      Counter64
  2100.           MAX-ACCESS  read-only
  2101.           STATUS      current
  2102.           DESCRIPTION
  2103.                   "The number of packets, delivered by this sub-layer to
  2104.                   a higher (sub-)layer, which were addressed to a
  2105.                   multicast address at this sub-layer.  For a MAC layer
  2106.                   protocol, this includes both Group and Functional
  2107.                   addresses.  This object is a 64-bit version of
  2108.                   ifInMulticastPkts."
  2109.           ::= { ifXEntry 8 }
  2110.  
  2111.       ifHCInBroadcastPkts OBJECT-TYPE
  2112.           SYNTAX      Counter64
  2113.           MAX-ACCESS  read-only
  2114.           STATUS      current
  2115.           DESCRIPTION
  2116.                   "The number of packets, delivered by this sub-layer to
  2117.                   a higher (sub-)layer, which were addressed to a
  2118.                   broadcast address at this sub-layer.  This object is a
  2119.                   64-bit version of ifInBroadcastPkts."
  2120.           ::= { ifXEntry 9 }
  2121.  
  2122.       ifHCOutOctets OBJECT-TYPE
  2123.           SYNTAX      Counter64
  2124.           MAX-ACCESS  read-only
  2125.           STATUS      current
  2126.           DESCRIPTION
  2127.                   "The total number of octets transmitted out of the
  2128.                   interface, including framing characters.  This object
  2129.                   is a 64-bit version of ifOutOctets."
  2130.           ::= { ifXEntry 10 }
  2131.  
  2132.       ifHCOutUcastPkts OBJECT-TYPE
  2133.           SYNTAX      Counter64
  2134.           MAX-ACCESS  read-only
  2135.           STATUS      current
  2136.           DESCRIPTION
  2137.                   "The total number of packets that higher-level
  2138.                   protocols requested be transmitted, and which were not
  2139.  
  2140.  
  2141.  
  2142.  
  2143.  
  2144.       Expires 26 March 1994                                    [Page 37]
  2145.  
  2146.  
  2147.  
  2148.  
  2149.       Draft               Interfaces Group Evolution   26 September 1993
  2150.  
  2151.  
  2152.                   addressed to a multicast or broadcast address at this
  2153.                   sub-layer, including those that were discarded or not
  2154.                   sent.  This object is a 64-bit version of
  2155.                   ifOutUcastPkts."
  2156.           ::= { ifXEntry 11 }
  2157.  
  2158.       ifHCOutMulticastPkts OBJECT-TYPE
  2159.           SYNTAX      Counter64
  2160.           MAX-ACCESS  read-only
  2161.           STATUS      current
  2162.           DESCRIPTION
  2163.                   "The total number of packets that higher-level
  2164.                   protocols requested be transmitted, and which were
  2165.                   addressed to a multicast address at this sub-layer,
  2166.                   including those that were discarded or not sent.  For
  2167.                   a MAC layer protocol, this includes both Group and
  2168.                   Functional addresses.  This object is a 64-bit version
  2169.                   of ifOutMulticastPkts."
  2170.           ::= { ifXEntry 12 }
  2171.  
  2172.       ifHCOutBroadcastPkts OBJECT-TYPE
  2173.           SYNTAX      Counter64
  2174.           MAX-ACCESS  read-only
  2175.           STATUS      current
  2176.           DESCRIPTION
  2177.                   "The total number of packets that higher-level
  2178.                   protocols requested be transmitted, and which were
  2179.                   addressed to a broadcast address at this sub-layer,
  2180.                   including those that were discarded or not sent.  This
  2181.                   object is a 64-bit version of ifOutBroadcastPkts."
  2182.           ::= { ifXEntry 13 }
  2183.  
  2184.       ifLinkUpDownTrapEnable  OBJECT-TYPE
  2185.           SYNTAX      INTEGER { enabled(1), disabled(2) }
  2186.           MAX-ACCESS  read-write
  2187.           STATUS      current
  2188.           DESCRIPTION
  2189.                   "Indicates whether linkUp/linkDown traps should be
  2190.                   generated for this interface.
  2191.  
  2192.                   By default, this object should have the value
  2193.                   enabled(1) for interfaces which do not operate on
  2194.                   'top' of any other interface (as defined in the
  2195.                   ifStackTable), and disabled(2) otherwise."
  2196.           ::= { ifXEntry 14 }
  2197.  
  2198.  
  2199.  
  2200.  
  2201.  
  2202.       Expires 26 March 1994                                    [Page 38]
  2203.  
  2204.  
  2205.  
  2206.  
  2207.       Draft               Interfaces Group Evolution   26 September 1993
  2208.  
  2209.  
  2210.       ifHighSpeed OBJECT-TYPE
  2211.           SYNTAX      Gauge32
  2212.           MAX-ACCESS  read-only
  2213.           STATUS      current
  2214.           DESCRIPTION
  2215.                   "An estimate of the interface's current bandwidth in
  2216.                   units of 1,000,000 bits per second.  If this object
  2217.                   reports a value of `n' then the speed of the interface
  2218.                   is somewhere in the range of `n-500,000' to
  2219.                   `n+499,999'.  For interfaces which do not vary in
  2220.                   bandwidth or for those where no accurate estimation
  2221.                   can be made, this object should contain the nominal
  2222.                   bandwidth.  For a sub-layer which has no concept of
  2223.                   bandwidth, this object should be zero."
  2224.           ::= { ifXEntry 15 }
  2225.  
  2226.       ifPromiscuousMode  OBJECT-TYPE
  2227.           SYNTAX      TruthValue
  2228.           MAX-ACCESS  read-write
  2229.           STATUS      current
  2230.           DESCRIPTION
  2231.                   "This object has a value of false(2) if this interface
  2232.                   only accepts packets/frames that are addressed to this
  2233.                   station.  This object has a value of true(1) when the
  2234.                   station accepts all packets/frames transmitted on the
  2235.                   media.  The value true(1) is only legal on certain
  2236.                   types of media.  If legal, setting this object to a
  2237.                   value of true(1) may require the interface to be reset
  2238.                   before becoming effective.
  2239.  
  2240.                   The value of ifPromiscuousMode does not affect the
  2241.                   reception of broadcast and multicast packets/frames by
  2242.                   the interface."
  2243.           ::= { ifXEntry 16 }
  2244.  
  2245.  
  2246.  
  2247.  
  2248.  
  2249.  
  2250.  
  2251.  
  2252.  
  2253.  
  2254.  
  2255.  
  2256.  
  2257.  
  2258.  
  2259.  
  2260.       Expires 26 March 1994                                    [Page 39]
  2261.  
  2262.  
  2263.  
  2264.  
  2265.       Draft               Interfaces Group Evolution   26 September 1993
  2266.  
  2267.  
  2268.       --           The Interface Stack Group
  2269.       --
  2270.       -- Implementation of this group is mandatory for all systems
  2271.       --
  2272.  
  2273.       ifStackTable  OBJECT-TYPE
  2274.            SYNTAX        SEQUENCE OF IfStackEntry
  2275.            MAX-ACCESS    not-accessible
  2276.            STATUS        current
  2277.            DESCRIPTION
  2278.                   "The table containing information on the relationships
  2279.                   between the multiple sub-layers of network interfaces.
  2280.                   In particular, it contains information on which sub-
  2281.                   layers run 'on top of' which other sub-layers.  Each
  2282.                   sub-layer corresponds to a conceptual row in the
  2283.                   ifTable."
  2284.            ::= { ifMIBObjects 2 }
  2285.  
  2286.  
  2287.       ifStackEntry  OBJECT-TYPE
  2288.            SYNTAX        IfStackEntry
  2289.            MAX-ACCESS    not-accessible
  2290.            STATUS        current
  2291.            DESCRIPTION
  2292.                   "Information on a particular relationship between two
  2293.                   sub-layers, specifying that one sub-layer runs on
  2294.                   'top' of the other sub-layer.  Each sub-layer
  2295.                   corresponds to a conceptual row in the ifTable."
  2296.            INDEX { ifStackHigherLayer, ifStackLowerLayer }
  2297.            ::= { ifStackTable 1 }
  2298.  
  2299.  
  2300.       IfStackEntry ::=
  2301.           SEQUENCE {
  2302.               ifStackHigherLayer  Integer32,
  2303.               ifStackLowerLayer   Integer32,
  2304.               ifStackStatus       RowStatus
  2305.            }
  2306.  
  2307.  
  2308.       ifStackHigherLayer  OBJECT-TYPE
  2309.            SYNTAX        Integer32
  2310.            MAX-ACCESS    not-accessible
  2311.            STATUS        current
  2312.            DESCRIPTION
  2313.  
  2314.  
  2315.  
  2316.  
  2317.  
  2318.       Expires 26 March 1994                                    [Page 40]
  2319.  
  2320.  
  2321.  
  2322.  
  2323.       Draft               Interfaces Group Evolution   26 September 1993
  2324.  
  2325.  
  2326.                   "The value of ifIndex corresponding to the higher
  2327.                   sub-layer of the relationship, i.e., the sub-layer
  2328.                   which runs on 'top' of the sub-layer identified by the
  2329.                   corresponding instance of ifStackLowerLayer.  If there
  2330.                   is no higher sub-layer (below the internetwork layer),
  2331.                   then this object has the value 0."
  2332.            ::= { ifStackEntry 1 }
  2333.  
  2334.  
  2335.       ifStackLowerLayer  OBJECT-TYPE
  2336.            SYNTAX        Integer32
  2337.            MAX-ACCESS    not-accessible
  2338.            STATUS        current
  2339.            DESCRIPTION
  2340.                   "The value of ifIndex corresponding to the lower sub-
  2341.                   layer of the relationship, i.e., the sub-layer which
  2342.                   runs 'below' the sub-layer identified by the
  2343.                   corresponding instance of ifStackHigherLayer.  If
  2344.                   there is no lower sub-layer, then this object has the
  2345.                   value 0."
  2346.            ::= { ifStackEntry 2 }
  2347.  
  2348.  
  2349.       ifStackStatus  OBJECT-TYPE
  2350.           SYNTAX         RowStatus
  2351.           MAX-ACCESS     read-write
  2352.           STATUS         current
  2353.           DESCRIPTION
  2354.                   "The status of the relationship between two sub-
  2355.                   layers.
  2356.  
  2357.                   Changing the value of this object from 'active' to
  2358.                   'notInService' or 'destroy' will likely have
  2359.                   consequences up and down the interface stack.  Thus,
  2360.                   write access to this object is likely to be
  2361.                   inappropriate for some types of interfaces, and many
  2362.                   implementations will choose not to support write-
  2363.                   access for any type of interface."
  2364.           ::= { ifStackEntry 3 }
  2365.  
  2366.  
  2367.  
  2368.  
  2369.  
  2370.  
  2371.  
  2372.  
  2373.  
  2374.  
  2375.  
  2376.       Expires 26 March 1994                                    [Page 41]
  2377.  
  2378.  
  2379.  
  2380.  
  2381.       Draft               Interfaces Group Evolution   26 September 1993
  2382.  
  2383.  
  2384.       --
  2385.       --    The Interface Test Table
  2386.       --
  2387.       -- This group of objects is optional.  However, a media-specific
  2388.       -- MIB may make implementation of this group mandatory.
  2389.       --
  2390.       -- This table replaces the ifExtnsTestTable
  2391.       --
  2392.  
  2393.       ifTestTable   OBJECT-TYPE
  2394.           SYNTAX      SEQUENCE OF IfTestEntry
  2395.           MAX-ACCESS  not-accessible
  2396.           STATUS      current
  2397.           DESCRIPTION
  2398.                   "This table contains one entry per interface.  It
  2399.                   defines objects which allow a network manager to
  2400.                   instruct an agent to test an interface for various
  2401.                   faults.  Tests for an interface are defined in the
  2402.                   media-specific MIB for that interface.  After invoking
  2403.                   a test, the object ifTestResult can be read to
  2404.                   determine the outcome.  If an agent can not perform
  2405.                   the test, ifTestResult is set to so indicate.  The
  2406.                   object ifTestCode can be used to provide further
  2407.                   test-specific or interface-specific (or even
  2408.                   enterprise-specific) information concerning the
  2409.                   outcome of the test.  Only one test can be in progress
  2410.                   on each interface at any one time.  If one test is in
  2411.                   progress when another test is invoked, the second test
  2412.                   is rejected.  Some agents may reject a test when a
  2413.                   prior test is active on another interface.
  2414.  
  2415.                   Before starting a test, a manager-station must first
  2416.                   obtain 'ownership' of the entry in the ifTestTable for
  2417.                   the interface to be tested.  This is accomplished with
  2418.                   the ifTestId and ifTestStatus objects as follows:
  2419.  
  2420.                try_again:
  2421.                    get (ifTestId, ifTestStatus)
  2422.                    while (ifTestStatus != notInUse)
  2423.                        /*
  2424.                         * Loop while a test is running or some other
  2425.                         * manager is configuring a test.
  2426.                         */
  2427.                        short delay
  2428.                        get (ifTestId, ifTestStatus)
  2429.  
  2430.  
  2431.  
  2432.  
  2433.  
  2434.       Expires 26 March 1994                                    [Page 42]
  2435.  
  2436.  
  2437.  
  2438.  
  2439.       Draft               Interfaces Group Evolution   26 September 1993
  2440.  
  2441.  
  2442.                    }
  2443.  
  2444.                    /*
  2445.                     * Is not being used right now -- let's compete
  2446.                     * to see who gets it.
  2447.                     */
  2448.                    lock_value = ifTestId
  2449.  
  2450.                    if ( set(ifTestId = lock_value, ifTestStatus = inUse,
  2451.                             ifTestOwner = 'my-IP-address') == FAILURE)
  2452.                        /*
  2453.                         * Another manager got the ifTestEntry -- go
  2454.                         * try again
  2455.                         */
  2456.                        goto try_again;
  2457.  
  2458.                    /*
  2459.                     * I have the lock
  2460.                     */
  2461.                    set up any test parameters.
  2462.  
  2463.                    /*
  2464.                     * This starts the test
  2465.                     */
  2466.                    set(ifTestType = test_to_run);
  2467.  
  2468.                    wait for test completion by polling ifTestResult
  2469.  
  2470.                    when test completes, agent sets ifTestResult
  2471.                         agent also sets ifTestStatus = 'notInUse'
  2472.  
  2473.                    retrieve any additional test results, and ifTestId
  2474.  
  2475.                    if (ifTestId == lock_value+1) results are valid
  2476.  
  2477.                  A manager station first retrieves the value of the
  2478.                  appropriate ifTestId and ifTestStatus objects,
  2479.                  periodically repeating the retrieval if necessary,
  2480.                  until the value of ifTestStatus is 'notInUse'.  The
  2481.                  manager station then tries to set the same ifTestId
  2482.                  object to the value it just retrieved, the same
  2483.                  ifTestStatus object to 'inUse', and the corresponding
  2484.                  ifTestOwner object to a value indicating itself.  If
  2485.                  the set operation succeeds then the manager has
  2486.                  obtained ownership of the ifTestEntry, and the value of
  2487.  
  2488.  
  2489.  
  2490.  
  2491.  
  2492.       Expires 26 March 1994                                    [Page 43]
  2493.  
  2494.  
  2495.  
  2496.  
  2497.       Draft               Interfaces Group Evolution   26 September 1993
  2498.  
  2499.  
  2500.                  the ifTestId object is incremented by the agent (per
  2501.                  the semantics of TestAndIncr).  Failure of the set
  2502.                  operation indicates that some other manager has
  2503.                  obtained ownership of the ifTestEntry.
  2504.  
  2505.                  Once ownership is obtained, any test parameters can be
  2506.                  setup, and then the test is initiated by setting
  2507.                  ifTestType.  On completion of the test, the agent sets
  2508.                  ifTestStatus to 'notInUse'.  Once this occurs, the
  2509.                  manager can retrieve the results.  In the (rare) event
  2510.                  that the invocation of tests by two network managers
  2511.                  were to overlap, then there would be a possibility that
  2512.                  the first test's results might be overwritten by the
  2513.                  second test's results prior to the first results being
  2514.                  read.  This unlikely circumstance can be detected by a
  2515.                  network manager retrieving ifTestId at the same time as
  2516.                  retrieving the test results, and ensuring that the
  2517.                  results are for the desired request.
  2518.  
  2519.                  If ifTestType is not set within an abnormally long
  2520.                  period of time after ownership is obtained, the agent
  2521.                  should time-out the manager, and reset the value of the
  2522.                  ifTestStatus object back to 'notInUse'.  It is
  2523.                  suggested that this time-out period be 5 minutes.
  2524.  
  2525.                  In general, a management station must not retransmit a
  2526.                  request to invoke a test for which it does not receive
  2527.                  a response; instead, it properly inspects an agent's
  2528.                  MIB to determine if the invocation was successful.
  2529.                  Only if the invocation was unsuccessful, is the
  2530.                  invocation request retransmitted.
  2531.  
  2532.                  Some tests may require the interface to be taken off-
  2533.                  line in order to execute them, or may even require the
  2534.                  agent to reboot after completion of the test.  In these
  2535.                  circumstances, communication with the management
  2536.                  station invoking the test may be lost until after
  2537.                  completion of the test.  An agent is not required to
  2538.                  support such tests.  However, if such tests are
  2539.                  supported, then the agent should make every effort to
  2540.                  transmit a response to the request which invoked the
  2541.                  test prior to losing communication.  When the agent is
  2542.                  restored to normal service, the results of the test are
  2543.                  properly made available in the appropriate objects.
  2544.                  Note that this requires that the ifIndex value assigned
  2545.  
  2546.  
  2547.  
  2548.  
  2549.  
  2550.       Expires 26 March 1994                                    [Page 44]
  2551.  
  2552.  
  2553.  
  2554.  
  2555.       Draft               Interfaces Group Evolution   26 September 1993
  2556.  
  2557.  
  2558.                  to an interface must be unchanged even if the test
  2559.                  causes a reboot.  An agent must reject any test for
  2560.                  which it cannot, perhaps due to resource constraints,
  2561.                  make available at least the minimum amount of
  2562.                  information after that test completes."
  2563.           ::= { ifMIBObjects 3 }
  2564.  
  2565.       ifTestEntry OBJECT-TYPE
  2566.           SYNTAX       IfTestEntry
  2567.           MAX-ACCESS   not-accessible
  2568.           STATUS       current
  2569.           DESCRIPTION
  2570.                   "An entry containing objects for invoking tests on an
  2571.                   interface."
  2572.           AUGMENTS  { ifEntry }
  2573.           ::= { ifTestTable 1 }
  2574.  
  2575.       IfTestEntry ::=
  2576.           SEQUENCE {
  2577.               ifTestId           TestAndIncr,
  2578.               ifTestStatus       INTEGER,
  2579.               ifTestType         AutonomousType,
  2580.               ifTestResult       INTEGER,
  2581.               ifTestCode         OBJECT IDENTIFIER,
  2582.               ifTestOwner        OwnerString
  2583.           }
  2584.  
  2585.       ifTestId         OBJECT-TYPE
  2586.           SYNTAX       TestAndIncr
  2587.           MAX-ACCESS   read-write
  2588.           STATUS       current
  2589.           DESCRIPTION
  2590.                   "This object identifies the current invocation of the
  2591.                   interface's test."
  2592.           ::= { ifTestEntry 1 }
  2593.  
  2594.       ifTestStatus     OBJECT-TYPE
  2595.           SYNTAX       INTEGER { notInUse(1), inUse(2) }
  2596.           MAX-ACCESS   read-write
  2597.           STATUS       current
  2598.           DESCRIPTION
  2599.                   "This object indicates whether or not some manager
  2600.                   currently has the necessary 'ownership' required to
  2601.                   invoke a test on this interface.  A write to this
  2602.                   object is only successful when it changes its value
  2603.  
  2604.  
  2605.  
  2606.  
  2607.  
  2608.       Expires 26 March 1994                                    [Page 45]
  2609.  
  2610.  
  2611.  
  2612.  
  2613.       Draft               Interfaces Group Evolution   26 September 1993
  2614.  
  2615.  
  2616.                   from 'notInUse(1)' to 'inUse(2)'.  After completion of
  2617.                   a test, the agent resets the value back to
  2618.                   'notInUse(1)'."
  2619.           ::= { ifTestEntry 2 }
  2620.  
  2621.       ifTestType       OBJECT-TYPE
  2622.           SYNTAX       AutonomousType
  2623.           MAX-ACCESS   read-write
  2624.           STATUS       current
  2625.           DESCRIPTION
  2626.                   "A control variable used to start and stop operator-
  2627.                   initiated interface tests.  Most OBJECT IDENTIFIER
  2628.                   values assigned to tests are defined elsewhere, in
  2629.                   association with specific types of interface.
  2630.                   However, this document assigns a value for a full-
  2631.                   duplex loopback test, and defines the special meanings
  2632.                   of the subject identifier:
  2633.  
  2634.                       noTest  OBJECT IDENTIFIER ::= { 0 0 }
  2635.  
  2636.                   When the value noTest is written to this object, no
  2637.                   action is taken unless a test is in progress, in which
  2638.                   case the test is aborted.  Writing any other value to
  2639.                   this object is only valid when no test is currently in
  2640.                   progress, in which case the indicated test is
  2641.                   initiated.
  2642.  
  2643.                   When read, this object always returns the most recent
  2644.                   value that ifTestType was set to.  If it has not been
  2645.                   set since the last initialization of the network
  2646.                   management subsystem on the agent, a value of noTest
  2647.                   is returned."
  2648.           ::= { ifTestEntry 3 }
  2649.  
  2650.       ifTestResult  OBJECT-TYPE
  2651.           SYNTAX       INTEGER {
  2652.                            none(1),          -- no test yet requested
  2653.                            success(2),
  2654.                            inProgress(3),
  2655.                            notSupported(4),
  2656.                            unAbleToRun(5),   -- due to state of system
  2657.                            aborted(6),
  2658.                            failed(7)
  2659.                        }
  2660.           MAX-ACCESS   read-only
  2661.  
  2662.  
  2663.  
  2664.  
  2665.  
  2666.       Expires 26 March 1994                                    [Page 46]
  2667.  
  2668.  
  2669.  
  2670.  
  2671.       Draft               Interfaces Group Evolution   26 September 1993
  2672.  
  2673.  
  2674.           STATUS       current
  2675.           DESCRIPTION
  2676.                   "This object contains the result of the most recently
  2677.                   requested test, or the value none(1) if no tests have
  2678.                   been requested since the last reset.  Note that this
  2679.                   facility provides no provision for saving the results
  2680.                   of one test when starting another, as could be
  2681.                   required if used by multiple managers concurrently."
  2682.           ::= { ifTestEntry 4 }
  2683.  
  2684.       ifTestCode  OBJECT-TYPE
  2685.           SYNTAX       OBJECT IDENTIFIER
  2686.           MAX-ACCESS   read-only
  2687.           STATUS       current
  2688.           DESCRIPTION
  2689.                   "This object contains a code which contains more
  2690.                   specific information on the test result, for example
  2691.                   an error-code after a failed test.  Error codes and
  2692.                   other values this object may take are specific to the
  2693.                   type of interface and/or test.  The value may have the
  2694.                   semantics of either the AutonomousType or
  2695.                   InstancePointer textual conventions as defined in RFC
  2696.                   1443.  The identifier:
  2697.  
  2698.                       testCodeUnknown  OBJECT IDENTIFIER ::= { 0 0 }
  2699.  
  2700.                   is defined for use if no additional result code is
  2701.                   available."
  2702.           ::= { ifTestEntry 5 }
  2703.  
  2704.       ifTestOwner      OBJECT-TYPE
  2705.           SYNTAX       OwnerString
  2706.           MAX-ACCESS   read-write
  2707.           STATUS       current
  2708.           DESCRIPTION
  2709.                   "The entity which currently has the 'ownership'
  2710.                   required to invoke a test on this interface."
  2711.           ::= { ifTestEntry 6 }
  2712.  
  2713.  
  2714.  
  2715.  
  2716.  
  2717.  
  2718.  
  2719.  
  2720.  
  2721.  
  2722.  
  2723.  
  2724.       Expires 26 March 1994                                    [Page 47]
  2725.  
  2726.  
  2727.  
  2728.  
  2729.       Draft               Interfaces Group Evolution   26 September 1993
  2730.  
  2731.  
  2732.       --   Generic Receive Address Table
  2733.       --
  2734.       -- This group of objects is mandatory for all types of
  2735.       -- interfaces which can receive packets/frames addressed to
  2736.       -- more than one address.
  2737.       --
  2738.       -- This table replaces the ifExtnsRcvAddr table.  The main
  2739.       -- difference is that this table makes use of the RowStatus
  2740.       -- textual convention, while ifExtnsRcvAddr did not.
  2741.  
  2742.       ifRcvAddressTable  OBJECT-TYPE
  2743.           SYNTAX      SEQUENCE OF IfRcvAddressEntry
  2744.           MAX-ACCESS  not-accessible
  2745.           STATUS      current
  2746.           DESCRIPTION
  2747.                   "This table contains an entry for each address
  2748.                   (broadcast, multicast, or uni-cast) for which the
  2749.                   system will receive packets/frames on a particular
  2750.                   interface, except as follows:
  2751.  
  2752.                   - for an interface operating in promiscuous mode,
  2753.                   entries are only required for those addresses for
  2754.                   which the system would receive frames were it not
  2755.                   operating in promiscuous mode.
  2756.  
  2757.                   - for 802.5 functional addresses, only one entry is
  2758.                   required, for the address which has the functional
  2759.                   address bit ANDed with the bit mask of all functional
  2760.                   addresses for which the interface will accept frames."
  2761.           ::= { ifMIBObjects 4 }
  2762.  
  2763.       ifRcvAddressEntry  OBJECT-TYPE
  2764.           SYNTAX      IfRcvAddressEntry
  2765.           MAX-ACCESS  not-accessible
  2766.           STATUS      current
  2767.           DESCRIPTION
  2768.                   "A list of objects identifying an address for which
  2769.                   the system will accept packets/frames on the
  2770.                   particular interface identified by the index value
  2771.                   ifIndex."
  2772.           INDEX  { ifIndex, ifRcvAddressAddress }
  2773.           ::= { ifRcvAddressTable 1 }
  2774.  
  2775.       IfRcvAddressEntry ::=
  2776.           SEQUENCE {
  2777.  
  2778.  
  2779.  
  2780.  
  2781.  
  2782.       Expires 26 March 1994                                    [Page 48]
  2783.  
  2784.  
  2785.  
  2786.  
  2787.       Draft               Interfaces Group Evolution   26 September 1993
  2788.  
  2789.  
  2790.               ifRcvAddressAddress   PhysAddress,
  2791.               ifRcvAddressStatus    RowStatus,
  2792.               ifRcvAddressType      INTEGER
  2793.           }
  2794.  
  2795.       ifRcvAddressAddress OBJECT-TYPE
  2796.           SYNTAX      PhysAddress
  2797.           MAX-ACCESS  read-create
  2798.           STATUS      current
  2799.           DESCRIPTION
  2800.                   "An address for which the system will accept
  2801.                   packets/frames on this entry's interface."
  2802.           ::= { ifRcvAddressEntry 1 }
  2803.  
  2804.       ifRcvAddressStatus OBJECT-TYPE
  2805.           SYNTAX      RowStatus
  2806.           MAX-ACCESS  read-write
  2807.           STATUS      current
  2808.           DESCRIPTION
  2809.                   "This object is used to create and delete rows in the
  2810.                   ifRcvAddressTable."
  2811.  
  2812.           ::= { ifRcvAddressEntry 2 }
  2813.  
  2814.       ifRcvAddressType OBJECT-TYPE
  2815.           SYNTAX      INTEGER {
  2816.                           other(1),
  2817.                           volatile(2),
  2818.                           nonVolatile(3)
  2819.                       }
  2820.  
  2821.           MAX-ACCESS  read-create
  2822.           STATUS      current
  2823.           DESCRIPTION
  2824.                   "This object has the value nonVolatile(3) for those
  2825.                   entries in the table which are valid and will not be
  2826.                   deleted by the next restart of the managed system.
  2827.                   Entries having the value volatile(2) are valid and
  2828.                   exist, but have not been saved, so that will not exist
  2829.                   after the next restart of the managed system.  Entries
  2830.                   having the value other(1) are valid and exist but are
  2831.                   not classified as to whether they will continue to
  2832.                   exist after the next restart."
  2833.  
  2834.           DEFVAL  { volatile }
  2835.  
  2836.  
  2837.  
  2838.  
  2839.  
  2840.       Expires 26 March 1994                                    [Page 49]
  2841.  
  2842.  
  2843.  
  2844.  
  2845.       Draft               Interfaces Group Evolution   26 September 1993
  2846.  
  2847.  
  2848.           ::= { ifRcvAddressEntry 3 }
  2849.  
  2850.  
  2851.  
  2852.  
  2853.  
  2854.  
  2855.  
  2856.  
  2857.  
  2858.  
  2859.  
  2860.  
  2861.  
  2862.  
  2863.  
  2864.  
  2865.  
  2866.  
  2867.  
  2868.  
  2869.  
  2870.  
  2871.  
  2872.  
  2873.  
  2874.  
  2875.  
  2876.  
  2877.  
  2878.  
  2879.  
  2880.  
  2881.  
  2882.  
  2883.  
  2884.  
  2885.  
  2886.  
  2887.  
  2888.  
  2889.  
  2890.  
  2891.  
  2892.  
  2893.  
  2894.  
  2895.  
  2896.  
  2897.  
  2898.       Expires 26 March 1994                                    [Page 50]
  2899.  
  2900.  
  2901.  
  2902.  
  2903.       Draft               Interfaces Group Evolution   26 September 1993
  2904.  
  2905.  
  2906.       -- conformance information
  2907.  
  2908.       ifConformance OBJECT IDENTIFIER ::= { ifMIB 2 }
  2909.  
  2910.       ifGroups      OBJECT IDENTIFIER ::= { ifConformance 1 }
  2911.       ifCompliances OBJECT IDENTIFIER ::= { ifConformance 2 }
  2912.  
  2913.  
  2914.       -- compliance statements
  2915.  
  2916.       ifCompliance MODULE-COMPLIANCE
  2917.           STATUS  current
  2918.           DESCRIPTION
  2919.                   "The compliance statement for SNMPv2 entities which
  2920.                   have network interfaces."
  2921.  
  2922.           MODULE  -- this module
  2923.               MANDATORY-GROUPS { ifGeneralGroup, ifStackGroup }
  2924.  
  2925.               GROUP       ifCharacterGroup
  2926.               DESCRIPTION
  2927.                   "This group is mandatory for all network interfaces
  2928.                   which are character-oriented or packet-oriented."
  2929.  
  2930.               GROUP       ifHCCharacterGroup
  2931.               DESCRIPTION
  2932.                   "This group is mandatory only for those network
  2933.                   interfaces which are character-oriented or packet-
  2934.                   oriented, and for which the value of the corresponding
  2935.                   instance of ifSpeed is greater than 20,000,000
  2936.                   bits/second."
  2937.  
  2938.               GROUP       ifPacketGroup
  2939.               DESCRIPTION
  2940.                   "This group is mandatory for all network interfaces
  2941.                   which are packet-oriented."
  2942.  
  2943.               GROUP       ifHCPacketGroup
  2944.               DESCRIPTION
  2945.                   "This group is mandatory only for those network
  2946.                   interfaces which are packet-oriented and for which the
  2947.                   value of the corresponding instance of ifSpeed is
  2948.                   greater than 650,000,000 bits/second."
  2949.  
  2950.               GROUP       ifTestGroup
  2951.  
  2952.  
  2953.  
  2954.  
  2955.  
  2956.       Expires 26 March 1994                                    [Page 51]
  2957.  
  2958.  
  2959.  
  2960.  
  2961.       Draft               Interfaces Group Evolution   26 September 1993
  2962.  
  2963.  
  2964.               DESCRIPTION
  2965.                   "This group is optional.  Media-specific MIBs which
  2966.                   require interface tests are strongly encouraged to use
  2967.                   this group for invoking tests and reporting results.
  2968.                   A medium specific MIB which has mandatory tests may
  2969.                   make implementation of this group mandatory."
  2970.  
  2971.               GROUP       ifRcvAddressGroup
  2972.               DESCRIPTION
  2973.                   "The applicability of this group MUST be defined by
  2974.                   the media-specific MIBs.  Media-specific MIBs must
  2975.                   define the exact meaning, use, and semantics of the
  2976.                   addresses in this group."
  2977.  
  2978.               OBJECT      ifPromiscuousMode
  2979.               MIN-ACCESS  read-only
  2980.               DESCRIPTION
  2981.                   "Write access is not required."
  2982.  
  2983.               OBJECT      ifStackStatus
  2984.               SYNTAX      INTEGER { active(1) } -- subset of RowStatus
  2985.               MIN-ACCESS  read-only
  2986.               DESCRIPTION
  2987.                   "Write access is not required, and only one of the six
  2988.                   enumerated values for the RowStatus textual convention
  2989.                   need be supported, specifically: active(1)."
  2990.  
  2991.               OBJECT       ifAdminStatus
  2992.               SYNTAX       INTEGER { up(1), down(2) }
  2993.               MIN-ACCESS   read-only
  2994.               DESCRIPTION
  2995.                   "Write access is not required, nor is support for the
  2996.                   value testing(3)."
  2997.           ::= { ifCompliances 1 }
  2998.  
  2999.  
  3000.  
  3001.  
  3002.  
  3003.  
  3004.  
  3005.  
  3006.  
  3007.  
  3008.  
  3009.  
  3010.  
  3011.  
  3012.  
  3013.  
  3014.       Expires 26 March 1994                                    [Page 52]
  3015.  
  3016.  
  3017.  
  3018.  
  3019.       Draft               Interfaces Group Evolution   26 September 1993
  3020.  
  3021.  
  3022.       -- units of conformance
  3023.  
  3024.       ifGeneralGroup    OBJECT-GROUP
  3025.           OBJECTS { ifDescr, ifType, ifSpeed, ifPhysAddress,
  3026.                     ifAdminStatus, ifOperStatus, ifLastChange,
  3027.                     ifSpecific, ifLinkUpDownTrapEnable,
  3028.                     ifHighSpeed, ifName }
  3029.           STATUS  current
  3030.           DESCRIPTION
  3031.                   "A collection of objects providing information
  3032.                   applicable to all network interfaces."
  3033.           ::= { ifGroups 1 }
  3034.  
  3035.       ifCharacterGroup    OBJECT-GROUP
  3036.           OBJECTS { ifInOctets, ifOutOctets }
  3037.           STATUS  current
  3038.           DESCRIPTION
  3039.                   "A collection of objects providing information
  3040.                   specific to packet-oriented or character-oriented
  3041.                   network interfaces."
  3042.           ::= { ifGroups 2 }
  3043.  
  3044.       ifHCCharacterGroup    OBJECT-GROUP
  3045.           OBJECTS { ifHCInOctets, ifHCOutOctets }
  3046.           STATUS  current
  3047.           DESCRIPTION
  3048.                   "A collection of objects providing information
  3049.                   specific to high speed (greater than 20,000,000
  3050.                   bits/second) packet-oriented or character-oriented
  3051.                   network interfaces."
  3052.           ::= { ifGroups 3 }
  3053.  
  3054.       ifPacketGroup    OBJECT-GROUP
  3055.           OBJECTS { ifMtu, ifInUcastPkts, ifInMulticastPkts,
  3056.                     ifInBroadcastPkts, ifInDiscards, ifInErrors,
  3057.                     ifInUnknownProtos, ifOutUcastPkts,
  3058.                     ifOutMulticastPkts, ifOutBroadcastPkts,
  3059.                     ifOutDiscards, ifOutErrors, ifPromiscuousMode }
  3060.           STATUS  current
  3061.           DESCRIPTION
  3062.                   "A collection of objects providing information
  3063.                   specific to packet-oriented network interfaces."
  3064.           ::= { ifGroups 4 }
  3065.  
  3066.       ifHCPacketGroup    OBJECT-GROUP
  3067.  
  3068.  
  3069.  
  3070.  
  3071.  
  3072.       Expires 26 March 1994                                    [Page 53]
  3073.  
  3074.  
  3075.  
  3076.  
  3077.       Draft               Interfaces Group Evolution   26 September 1993
  3078.  
  3079.  
  3080.           OBJECTS { ifHCInUcastPkts, ifHCInMulticastPkts,
  3081.                     ifHCInBroadcastPkts, ifHCOutUcastPkts,
  3082.                     ifHCOutMulticastPkts, ifHCOutBroadcastPkts
  3083.                   }
  3084.           STATUS  current
  3085.           DESCRIPTION
  3086.                   "A collection of objects providing information
  3087.                   specific to high speed (greater than 650,000,000
  3088.                   bits/second) packet-oriented network interfaces."
  3089.           ::= { ifGroups 5 }
  3090.  
  3091.       ifRcvAddressGroup    OBJECT-GROUP
  3092.           OBJECTS { ifRcvAddressStatus, ifRcvAddressType }
  3093.           STATUS  current
  3094.           DESCRIPTION
  3095.                   "A collection of objects providing information on the
  3096.                   multiple addresses which an interface receives."
  3097.           ::= { ifGroups 6 }
  3098.  
  3099.  
  3100.       ifTestGroup    OBJECT-GROUP
  3101.           OBJECTS { ifTestId, ifTestStatus, ifTestType,
  3102.                     ifTestResult, ifTestCode, ifTestOwner }
  3103.           STATUS  current
  3104.           DESCRIPTION
  3105.                   "A collection of objects providing the ability to
  3106.                   invoke tests on an interface."
  3107.           ::= { ifGroups 7 }
  3108.  
  3109.       ifStackGroup    OBJECT-GROUP
  3110.           OBJECTS { ifStackStatus }
  3111.           STATUS  current
  3112.           DESCRIPTION
  3113.                   "A collection of objects providing information on the
  3114.                   layering of MIB-II interfaces."
  3115.           ::= { ifGroups 8 }
  3116.  
  3117.       END
  3118.  
  3119.  
  3120.  
  3121.  
  3122.  
  3123.  
  3124.  
  3125.  
  3126.  
  3127.  
  3128.  
  3129.  
  3130.       Expires 26 March 1994                                    [Page 54]
  3131.  
  3132.  
  3133.  
  3134.  
  3135.       Draft               Interfaces Group Evolution   26 September 1993
  3136.  
  3137.  
  3138.       6.  Acknowledgements
  3139.  
  3140.       This memo has been produced by the IETF's Interfaces MIB working-
  3141.       group.
  3142.  
  3143.       The initial proposal to the working-group was the result of
  3144.       conversations and discussions with many people, including at least
  3145.       the following: Fred Baker, Ted Brunner, Chuck Davin, Jeremy
  3146.       Greene, Marshall Rose, Kaj Tesink, and Dean Throop.
  3147.  
  3148.  
  3149.  
  3150.  
  3151.  
  3152.  
  3153.  
  3154.  
  3155.  
  3156.  
  3157.  
  3158.  
  3159.  
  3160.  
  3161.  
  3162.  
  3163.  
  3164.  
  3165.  
  3166.  
  3167.  
  3168.  
  3169.  
  3170.  
  3171.  
  3172.  
  3173.  
  3174.  
  3175.  
  3176.  
  3177.  
  3178.  
  3179.  
  3180.  
  3181.  
  3182.  
  3183.  
  3184.  
  3185.  
  3186.  
  3187.  
  3188.       Expires 26 March 1994                                    [Page 55]
  3189.  
  3190.  
  3191.  
  3192.  
  3193.       Draft               Interfaces Group Evolution   26 September 1993
  3194.  
  3195.  
  3196.       7.  References
  3197.  
  3198.       [1]  Case, J., McCloghrie, K., Rose, M., and S. Waldbusser,
  3199.            "Structure of Management Information for version 2 of the
  3200.            Simple Network Management Protocol (SNMPv2)", RFC 1442, SNMP
  3201.            Research, Inc., Hughes LAN Systems, Dover Beach Consulting,
  3202.            Inc., Carnegie Mellon University, April 1993.
  3203.  
  3204.  
  3205.       [2]  Galvin, J., and K. McCloghrie, "Administrative Model for
  3206.            version 2 of the Simple Network Management Protocol
  3207.            (SNMPv2)", RFC 1445, Trusted Information Systems, Hughes LAN
  3208.            Systems, April 1993.
  3209.  
  3210.  
  3211.       [3]  Case, J., McCloghrie, K., Rose, M., and S. Waldbusser,
  3212.            "Protocol Operations for version 2 of the Simple Network
  3213.            Management Protocol (SNMPv2)", RFC 1448, SNMP Research, Inc.,
  3214.            Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie
  3215.            Mellon University, April 1993.
  3216.  
  3217.  
  3218.       [4]  McCloghrie, K., and M. Rose, "Management Information Base for
  3219.            Network Management of TCP/IP-based internets - MIB-II", RFC
  3220.            1213, Hughes LAN Systems, Performance Systems International,
  3221.            March 1991.
  3222.  
  3223.  
  3224.       [5]  Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple
  3225.            Network Management Protocol", RFC 1157, SNMP Research,
  3226.            Performance Systems International, Performance Systems
  3227.            International, MIT Laboratory for Computer Science, May 1990.
  3228.  
  3229.  
  3230.       [6]  J. Postel, "Internet Protocol", RFC 791, Information Sciences
  3231.            Institute, USC, September 1981.
  3232.  
  3233.  
  3234.       [7]  K. McCloghrie, "Extensions to the Generic-Interface MIB", RFC
  3235.            1229, Hughes LAN Systems, May 1991.
  3236.  
  3237.  
  3238.  
  3239.  
  3240.  
  3241.  
  3242.  
  3243.  
  3244.  
  3245.  
  3246.       Expires 26 March 1994                                    [Page 56]
  3247.  
  3248.  
  3249.  
  3250.  
  3251.       Draft               Interfaces Group Evolution   26 September 1993
  3252.  
  3253.  
  3254.       8.  Security Considerations
  3255.  
  3256.       Security issues are not discussed in this memo.
  3257.  
  3258.  
  3259.       9.  Authors' Address
  3260.  
  3261.            Keith McCloghrie
  3262.            Hughes LAN Systems
  3263.            1225 Charleston Rd,
  3264.            Mountain View, Ca 94043
  3265.  
  3266.            Phone: 415-966-7934
  3267.            Email: kzm@hls.com
  3268.  
  3269.            Frank Kastenholz
  3270.            FTP Software
  3271.            2 High Street
  3272.            North Andover, Mass. USA 01845
  3273.  
  3274.            Phone: (508)685-4000
  3275.            Email: kasten@ftp.com
  3276.  
  3277.  
  3278.  
  3279.  
  3280.  
  3281.  
  3282.  
  3283.  
  3284.  
  3285.  
  3286.  
  3287.  
  3288.  
  3289.  
  3290.  
  3291.  
  3292.  
  3293.  
  3294.  
  3295.  
  3296.  
  3297.  
  3298.  
  3299.  
  3300.  
  3301.  
  3302.  
  3303.  
  3304.       Expires 26 March 1994                                    [Page 57]
  3305.  
  3306.  
  3307.  
  3308.  
  3309.       Draft               Interfaces Group Evolution   26 September 1993
  3310.  
  3311.  
  3312.       Table of Contents
  3313.  
  3314.  
  3315.       1 Introduction ..............................................    2
  3316.       1.1 Change Log ..............................................    2
  3317.       2 The SNMPv2 Network Management Framework ...................    6
  3318.       2.1 Object Definitions ......................................    6
  3319.       3 Experience with the Interfaces Group ......................    7
  3320.       3.1 Areas of Clarification/Revision .........................    7
  3321.       3.1.1 Interface Numbering ...................................    7
  3322.       3.1.2 Interface Sub-Layers ..................................    8
  3323.       3.1.3 Virtual Circuits ......................................    9
  3324.       3.1.4 Bit and Character Oriented Interfaces .................    9
  3325.       3.1.5 Counter Size ..........................................    9
  3326.       3.1.6 Interface Speed .......................................   10
  3327.       3.1.7 Multicast/Broadcast Counters ..........................   10
  3328.       3.2 Clarifications/Revisions ................................   10
  3329.       3.2.1 Interface Numbering ...................................   10
  3330.       3.2.2 Interface Sub-Layers ..................................   12
  3331.       3.2.3 Guidance on Defining Sub-layers .......................   14
  3332.       3.2.4 Virtual Circuits ......................................   15
  3333.       3.2.5 Bit and Character Oriented Interfaces .................   16
  3334.       3.2.6 Counter Size ..........................................   17
  3335.       3.2.7 Interface Speed .......................................   19
  3336.       3.2.8 Multicast/Broadcast Counters ..........................   20
  3337.       3.2.9 Trap Enable ...........................................   20
  3338.       3.3 Media-Specific MIB Applicability ........................   21
  3339.       4 Overview ..................................................   22
  3340.       5 Definitions ...............................................   23
  3341.       6 Acknowledgements ..........................................   55
  3342.       7 References ................................................   56
  3343.       8 Security Considerations ...................................   57
  3344.       9 Authors' Address ..........................................   57
  3345.  
  3346.  
  3347.  
  3348.  
  3349.  
  3350.  
  3351.  
  3352.  
  3353.  
  3354.  
  3355.  
  3356.  
  3357.  
  3358.  
  3359.  
  3360.  
  3361.  
  3362.       Expires 26 March 1994                                    [Page 58]
  3363.